2022 年，Linux 6.1 的合并窗口接纳了初步的 Rust 支持。消息很快被简化成“Linux 要用 Rust 重写”，但实际变化谨慎得多：内核只是建立了让部分新代码使用 Rust 的基础，还远没有替换数千万行 C。
即便如此，这一步仍然重要。因为它承认了一个现实：只依靠代码评审和开发者经验，很难彻底消灭 C 语言中的内存安全错误。
Rust 想解决哪一类问题
空指针、释放后使用、越界访问、数据竞争等问题，在系统软件中尤其危险。C 给开发者极高控制力，也把对象生命周期和并发正确性几乎全部交给人维护。
Rust 的所有权、借用和生命周期机制，把许多约束放进类型系统。编译器会拒绝一部分可能悬空的引用，并要求共享可变状态满足更严格的规则。它不能证明程序完全正确，却能在运行之前消灭一大类缺陷。
这不是“Rust 程序员更小心”，而是把过去依赖注意力的规则变成可重复执行的检查。对生命周期极长、权限极高的内核来说，这种转变特别有吸引力。
为什么不能直接重写
Linux 内核积累了几十年的驱动、架构支持和工程经验。完整重写不仅成本不可接受，还可能重新引入大量已经解决过的边界问题。安全的演进方式，是先为 Rust 建立最小支持，在新驱动或相对独立模块中验证，再逐步扩展抽象。
这也带来很多难题：Rust 标准库不能直接用于内核环境；C API 需要安全封装；内核对象的特殊生命周期未必能被普通所有权模型自然表达；工具链版本还必须与内核构建保持稳定。
真正困难的不是让一段 Rust 代码编译，而是设计一组“安全抽象”，确保普通驱动作者不需要频繁进入 unsafe，同时又不隐藏内核必须掌握的资源成本。
unsafe 不等于失败
Rust 允许在明确区域使用 unsafe 执行原始指针等操作。有人因此质疑内存安全承诺是否只是宣传。我认为恰恰相反：系统底层不可能没有危险操作，关键是能否把危险压缩到少数边界，并由专家集中审计。
C 中几乎每一行指针操作都隐含风险；Rust 希望把不变量封装起来，让上层调用者使用安全接口。安全不是没有风险，而是风险的位置可见、范围有限、规则可以验证。
我的理解：语言选择也是组织治理
一门语言进入内核，不只是跑分或语法之争。它涉及维护者是否愿意评审、工具链能否长期支持、文档是否完整、新旧社区怎样协作。技术优势如果不能转化为可维护流程，就不会自动产生可靠软件。
Rust 进入 Linux 的意义，是基础设施开始用新的方法管理复杂性：让编译器承担一部分人类容易遗漏的检查，把专家注意力留给协议、并发模型和硬件边界。
对普通后端开发者也有类似启示。我们不一定要把服务全部改写成 Rust，但应该寻找能把规则编码进类型、构建和测试系统的工具。只写在文档里的安全规范，最终总会遇到一个疲惫或不知情的开发者。
参考资料
本文是 2026 年整理断更期时写下的回顾，发布日期按事件所处阶段归档。