事件背景：Rust 缺的不是安全形象，而是合規語言
Rust 以所有權、借用檢查與型別系統，在編譯階段排除許多記憶體錯誤；但「語言較安全」不等於「專案已符合功能安全要求」。安全關鍵軟體仍須回答：哪些語法可用、例外如何核准、工具版本如何固定，以及每項限制如何留下可稽核證據。
由德國阿亨工業大學研究團隊提出的 MISRust，逐條檢視 MISRA C++:2023 的 179 項規範，判斷其設計理由能否移植到 Rust。論文於 2026 年 8 月更新至第二版，另有 SAFEComp 2026 論文集版本；arXiv 頁面仍明確標示該預印本本身未經同儕審查。原始資料見 https://arxiv.org/abs/2605.23490。
映射方法：移植的是風險理由，不是 C++ 語法
來源事實：研究將規則分為六類，其中一類是另一類的子集合。179 條規範中，15 條只處理 C++ 標準函式庫，42 條針對 Rust 根本沒有的特性，例如位元欄位與 goto，因此共有 57 條不適用。其餘 122 條與 Rust 有關：53 條已由語言設計自動滿足，58 條仍可直接適用，另有 11 條必須改寫。
這也解釋摘要中容易誤讀的 47.75%：分母不是全部 179 條，也不是 122 條，而是扣除 11 條「需要改寫」後的 111 條可原樣套用規範；其中 53 條由 Rust 自動滿足，53 除以 111 才是 47.75%。整體而言，仍有 69 條規範的安全意圖不能省略，即 58 條直接適用，加上 11 條需改寫。
這套方法的重要性，在於研究者沒有機械式翻譯條文，而是追問規則想防止什麼。例如，C++ 複雜標頭引用造成的名稱衝突，在 Rust 中可由匯入與重複定義檢查處理；但遞迴、動態記憶體配置、浮點數不精確及整數運算等風險，不會因改用 Rust 就消失。換句話說，編譯器能接手一部分「語法防錯」，卻無法代替系統層級的資源界線與失效行為設計。
真正的分界在 unsafe，而不是語言名稱
來源事實：在 58 條仍可直接適用的規範中，有 22 條即使只寫 Safe Rust 仍須遵守；另外 36 條在 Safe Rust 下由編譯器保證，但一旦引入 unsafe，便須重新納管。研究指出，重新出現的問題集中於生命週期、存取順序、裸指標、別名與資源共享，與 C、C++ 常見的核心風險相近。
Rust 官方參考文件也支持這個邊界的解讀：unsafe 並非關掉所有檢查，而是把編譯器無法驗證的安全義務交回程式設計者；unsafe 區塊代表開發者聲明相關前置條件已獲滿足。裸指標解參照、呼叫 unsafe 函式與外部介面，都是典型情境。詳見 https://doc.rust-lang.org/stable/reference/unsafe-keyword.html。
合理推論：未來若要把 MISRust 轉成工具，最有價值的不是再做一套通用風格檢查器，而是將 unsafe 邊界變成可稽核物件：限制出現位置、記錄安全契約、追蹤呼叫端、檢查裸指標操作，並把每次例外與風險評估連結起來。Rust 編譯器與 Clippy 可承擔部分自動檢查，但語意性的安全證明仍需要人工審查或更專門的靜態分析。
為何現在值得注意：工具鏈已先走到認證門口
安全關鍵 Rust 已不只是研究構想。Ferrocene 公開文件稱其 Rust 編譯器已取得 ISO 26262 ASIL D、IEC 61508 SIL 3 與 IEC 62304 Class C 對應資格；但其安全手冊同時列出明確的版本、主機、目標架構與函式庫範圍，並要求使用者自行確認工具信賴等級及實際使用環境。範圍說明見 https://public-docs.ferrocene.dev/main/safety-manual/scope.html。
作者觀點：這正好說明「合格編譯器」與「合格產品」是兩件事。前者提供可被安全流程接受的工具與證據；後者仍須處理需求追溯、架構分析、測試涵蓋、第三方套件、硬體互動及偏離規範的核准紀錄。MISRA 官方的合規指引也強調，合規只能針對特定專案主張，違規必須經明確程序授權並留下 deviation record，而非買到檢查工具便自動成立：https://www.misra.org.uk/app/uploads/2021/06/MISRA-Compliance-2020.pdf。
容易忽略的限制
這份研究不是可直接拿來宣告合規的正式 Rust 規範。分析以 rustc 1.92.0、Rust 2024 Edition 為基準，只涵蓋語言與標準函式庫，明確排除 C 外部函式介面；但嵌入式專案往往正是在驅動程式、暫存器存取、既有 C 函式庫與作業系統邊界使用 unsafe 或 FFI。
此外，179 條分類是由四名分析者人工判讀，沒有獨立外部複核，論文也承認語言演進可能改變結論。開源資料庫確實提供逐條分類與產生統計的程式，提升了可重現性，但可重現不等於分類必然正確。相關材料可查閱 https://github.com/embedded-software-laboratory/MISRust。
對台灣車電、工控與嵌入式團隊的意義
合理推論：對供應鏈廠商而言，最務實的採用路線不是一次改寫全部 C/C++，而是先建立可控的 Rust 區域：固定工具鏈與目標平台、預設禁止 unsafe、把必要的硬體或 FFI 操作集中於小型模組，再對這些邊界套用更嚴格的審查與追溯。如此才能把 Rust 的編譯期保證轉換成減少規範維護成本，而不是在新舊語言交界製造另一套黑盒。
採購與客戶稽核時，也應分別詢問「編譯器資格範圍」「核心函式庫是否納入」「第三方 crate 如何審查」及「unsafe 偏離如何留證」。這些問題比單問產品是否使用 Rust，更能判斷安全承諾是否落地。
後續觀察指標
- MISRust 的 69 條規範能否經獨立專家複核，形成具版本管理的公開規則集。
- 11 條改寫規範能否落實為 rustc、Clippy 或商用分析器可執行的檢查。
- unsafe、FFI、動態配置與第三方 crate 是否出現一致的審查及偏離紀錄格式。
- 合格工具鏈擴大支援的目標處理器、標準函式庫範圍與 Rust 版本，能否匹配量產專案週期。
MISRust 最有價值的訊息，不是「Rust 可以丟掉六成 MISRA 規則」，而是它首次較完整地標出：哪些風險已被語言吸收、哪些只是在 Safe Rust 中暫時隱形，以及哪些責任永遠屬於工程流程。安全關鍵 Rust 能否真正進入量產，最後取決於這張風險地圖能否被做成工具、證據與供應鏈共同接受的規則。