编译器已经在帮你"做安全"了------但要把 Rust 真正送进飞机、汽车和 ICU，还差什么？
背景：什么是"安全关键"软件？
在汽车、航空、医疗、工业自动化等领域，软件一旦出错，可能造成人身伤亡或环境灾难。这类软件被称为安全关键软件（Safety-Critical Software）。
各行业有对应的标准来管控风险：
| 行业 | 标准 | 完整性等级 |
|---|---|---|
| 汽车 | ISO 26262 | QM → ASIL A → ASIL B → ASIL C → ASIL D |
| 工业 | IEC 61508 | SIL 1 → SIL 2 → SIL 3 → SIL 4 |
| 医疗器械 | IEC 62304 | Class A / B / C |
| 航空 | DO-178C | DAL E → DAL A |
等级越高，对开发流程、验证方法和证据文件的要求就越严苛------成本也成倍增加。
Rust 已经在生产环境中跑起来了
这不是未来的故事，而是正在发生的现实。
工业机器人领域：一家移动机器人公司的首席固件工程师分享了他们的经历------过去用 C 语言开发 IEC 61508 SIL 2 级安全系统时，需要依赖昂贵且不好用的第三方静态分析工具；切换到 Rust 之后，"大约 90% 原本需要外部工具检查的内容，直接由编译器完成了"，加上已经有安全认证的 Rust 编译器可以引用，成为了一个真正的突破。
医疗设备领域 ：某公司正在向 ICU 重症监护室部署 IEC 62304 Class B 级别的 EEG（脑电图）分析软件，所有生产代码均用 Rust 编写，并且将原有的 Python 组件替换为 Rust 后，性能提升了 100 倍。
这些都是经过监管审计、真正在受控环境中运行的系统。路是有的，问题是怎么让后来者走得更容易。
Rust 的核心价值：让编译器来做安全工程师的工作
安全关键领域的工程师花费大量时间在防止内存错误、竞争条件、未定义行为上，而这些恰恰是 Rust 编译器天然强制保障的。
多位受访工程师指出：
- 约 90% 原本需要 MISRA C、CERT C 等外部规范或静态分析工具才能检查的问题，Rust 编译器在编译期就直接拦截了；
- Rust 对错误处理有统一且被生态系统广泛采用的方式（
Result+?运算符），减少了因"各写各的"引发的隐患； - 对于拥有数十甚至上百名开发者、产品生命周期长达 15~20 年的项目，编译器强制的不变量比"我们要更努力地做代码审查"更可扩展。
某汽车大厂的工程师说得很直白："我们无法控制每一位开发者的技能水平，必须依靠工具做代码质量把关。Rust 的编译期检查和 Clippy，对我们的领域非常有用。"
挑战一：越往高关键级走，生态越稀薄
Rust 在安全关键领域的采用，呈现出清晰的分层结构：
低关键级（QM 级）：相对自由
团队可以从 crates.io 自由引用第三方库，快速搭建原型，然后逐步加固。
高关键级（ASIL B+）：几乎寸步难行
第三方依赖难以通过审计，团队的典型做法是：
- 自行重写核心组件，不依赖任何第三方 crate；
- 构建抽象层，为未来替换做准备；
- 把 crates 当作"早期加速器"，在进入关键路径之前彻底清除。
一位航空领域的工程负责人说得更极端："在航空领域，我们必须拥有所有代码，必须掌控每一行代码。"
目前，以下关键基础设施在 Rust 生态中仍是空白或尚未成熟：
- 无 MATLAB/Simulink 的 Rust 代码生成
- 无与 OSEK / AUTOSAR Classic 兼容的 Rust RTOS
- 工具链认证与资质评定流程尚在完善中
挑战二：工具链稳定性 vs. 依赖漂移
安全关键团队倾向于锁定 Rust 工具链版本 ，以确保可重复构建。但问题随之而来------绝大多数 crate 都是面向最新版本编译器开发的，版本锁定会导致依赖降级，非常耗时。
某汽车大厂工程师抱怨道："我们可以锁定 Rust 工具链，但因为几乎所有 crate 都是为最新版本实现的，我们不得不反复降级。这非常耗时。"
值得庆幸的是，Rust 的 Edition 系统（版次机制）被多位受访者称赞为"对汽车行业是黄金"------它支持代码库的渐进式迁移，而非强迫一次性大改。
挑战三：目标平台支持有盲区
安全关键软件通常运行在长期维护的平台和 RTOS 上。即使 Rust 名义上"支持"某个目标，细节中可能藏着坑。例如，QNX 8.0 的 Rust 支持目前仅限于 no_std 模式，这对很多场景来说远远不够。
一位资深工程师描述了他的经历："有一次我升级编译器后，我们用的 Tier 3 目标的工具链和依赖全坏了。这完全不可接受。如果你要在某项技术上投入，就必须有一定的可靠性保障。"
挑战四：Async 的未来尚未清晰
异步编程对中间件、事件驱动架构非常有吸引力，但在安全关键场景中，async 意味着需要引入一个异步运行时------而运行时本身必须通过安全认证，其调度行为必须可预测、可验证。
一位开发 AUTOSAR Adaptive 平台中间件的团队负责人表示："如果我们要使用 async Rust，当然需要一个能为 ISO 26262 提供所有质量与流程产物的运行时。"
目前，Eclipse S-CORE 等项目正在尝试构建面向安全关键汽车软件的 Rust 异步运行时，但整个生态的认证路径仍在摸索中。
六大改进建议
Rust 官方博客在大量用户访谈基础上，提出了以下六条路线图建议：
1. 帮助安全关键社区自我赋能
参考 Ferrocene 语言规范（FLS）的成功模式------由产业界联合投入，成果归入 Rust 项目维护。类似地，MC/DC 覆盖率支持工作现已通过安全关键 Rust 联盟（Safety-Critical Rust Consortium）重启，以共同所有权模式推进。
2. 建立生态级 MSRV（最低支持 Rust 版本）公约
引入 LTS 发布版本，并鼓励库作者维护与 LTS 版本的兼容性，从源头解决依赖漂移问题。
3. 将"目标平台层级策略"转化为安全关键入门指南
整合现有文档，为每个目标平台提供一份清单：是否支持 no_std？最后验证的 OS 版本是什么？主要阻塞问题有哪些？
4. 整理"依赖生命周期"最佳实践手册
将各团队已在实践的经验（早期用 crate 加速、后期内化关键路径）整理成可复用的 Playbook。
5. 明确"安全案例友好型"异步运行时的需求规格
联合 async 工作组和 libs 团队，定义什么样的运行时才算满足 ISO 26262 等标准的要求。
6. 将 C/C++ 互操作纳入安全性故事
许多团队不会全量重写，而是将 Rust 集成进现有 C/C++ 系统。改善 FFI 边界的审计性和工具支持，是必须正视的工程挑战。
总结
| 维度 | 现状 |
|---|---|
| 生产落地 | 已有真实案例，工业/医疗/机器人均有部署 |
| 编译器安全保障 | 覆盖约 90% 传统外部工具的检查项 |
| 低关键级采用 | 流程顺畅，可用 crates 生态加速 |
| 高关键级采用 | 第三方依赖难过审，生态工具不成熟 |
| 工具链稳定性 | 版本锁定与依赖漂移之间存在张力 |
| 异步支持 | 技术可行，认证路径尚未成熟 |
| 目标平台支持 | 存在盲区，需要更清晰的文档 |
Rust 在安全关键系统领域的故事，已经从"能不能用"进化到"怎么用得更好"。路径是存在的，基础设施正在搭建中，生态正在成熟。
如果你正在安全关键领域使用 Rust，或者想为这一方向贡献力量，欢迎关注 Safety-Critical Rust Consortium 和 安全关键 Rust 编码指南。