2006年的一天,Graydon Hoare回到公寓,发现电梯又坏了。他住在21楼。

爬楼梯的时候,这位Mozilla的程序员越想越气。“我们这些搞计算机的,连个电梯软件都写不好?“他后来回忆道,“这太荒谬了。”

电梯软件为什么会崩溃?答案藏在内存里。这些嵌入式系统通常用C或C++编写,这两种语言赋予程序员对内存的绝对控制权——这种控制权是一把双刃剑。当程序忘记释放内存、或者访问了已经释放的内存区域,崩溃就来了。更糟糕的是,这类错误往往不会立即暴露,而是像一个定时炸弹,在最不合适的时候引爆。

Hoare那天回家后打开笔记本电脑,开始设计一门新的编程语言。他给它起名叫Rust——取自一类以"过度工程化的生存能力"著称的真菌。

十七年后,Rust成为Linux内核的官方支持语言。2025年12月,在年度内核维护者峰会上,Linus Torvalds和其他核心开发者正式决定:Rust不再是实验性功能,而是与C并列的核心开发语言。

一门2015年才发布1.0的语言,如何说服运行着全球数十亿设备的操作系统接受它?答案藏在两个数字里。

70%的问题

2019年,微软安全响应中心发布了一份报告:从2006年到2018年,微软产品中发现的安全漏洞中,约70%源于内存安全问题

这不是微软独有的困境。Google的Chrome团队给出的数字几乎相同:约70%的严重安全漏洞与内存安全相关。这些漏洞有一个共同的名字:缓冲区溢出、使用后释放(use-after-free)、双重释放、空指针解引用……

它们听起来像是教科书上的概念,但后果是真实的。2014年的Heartbleed漏洞让攻击者可以从服务器内存中读取敏感信息,影响了全球数百万网站。这类漏洞的根源,都是程序对内存的不当操作。

C和C++的问题在于它们假设程序员永远不会犯错。如果你写:

char* ptr = malloc(100);
// ... 一些代码 ...
free(ptr);
// ... 更多代码 ...
ptr[0] = 'a';  // 使用已经释放的内存

编译器会毫无怨言地接受这段代码。运行时,它会访问一块可能已被其他数据占用的内存——可能崩溃,可能静默地破坏数据,也可能被攻击者利用来执行任意代码。

为什么不用其他语言?

Java、Python、Go这些语言有垃圾回收机制(Garbage Collector),会自动管理内存,程序员不需要手动分配和释放。但垃圾回收是有代价的:

  • 性能开销:垃圾回收器需要定期暂停程序执行,扫描内存。对于响应时间要求严格的系统,这种停顿是不可接受的。
  • 内存占用:垃圾回收语言通常需要更多的内存来工作。云服务提供商Amazon Web Services发现,Rust代码运行时的电力消耗只有Java代码的一半——这意味着同样的数据中心可以承载两倍的工作负载。
  • 不可预测性:垃圾回收的触发时机不受程序员控制,这在实时系统中是一个严重问题。

系统编程——操作系统内核、数据库引擎、浏览器渲染引擎——需要C和C++级别的控制力。但传统上,这种控制力伴随着内存安全的风险。

Rust试图回答一个问题:能否在不牺牲控制力的前提下,消除内存安全问题?

所有权:一个反直觉的设计

Rust的解决方案叫做"所有权系统”(Ownership System)。它的核心思想可以概括为三条规则:

  1. 每一块数据都有且只有一个"所有者”(owner)
  2. 当所有者离开作用域,数据会被自动释放
  3. 数据可以被"借用"(borrow),但借用的规则极其严格

这些规则听起来简单,但它们的组合产生了深远的影响。

移动语义

在C++中,这段代码是完全合法的:

std::string a = "hello";
std::string b = a;  // a和b都指向同一块内存
// 程序结束时,两者的析构函数都会被调用
// 可能导致双重释放

Rust采用了不同的语义:

let a = String::from("hello");
let b = a;  // 所有权从a转移到b
// 此时a已经无效,任何对a的使用都会导致编译错误

当所有权转移后,原来的变量就"死亡"了。编译器会在编译时检查这一点,拒绝任何使用已失效变量的尝试。

借用规则

更精妙的是借用规则。Rust允许你创建数据的引用(借用),但有两条铁律:

  • 要么有一个可变引用,要么有任意数量的不可变引用,但不能同时存在
  • 引用必须始终有效(不能指向已经释放的内存)
let mut s = String::from("hello");

let r1 = &s;      // 不可变借用
let r2 = &s;      // 再来一个不可变借用,没问题
let r3 = &mut s;  // 编译错误!已有不可变借用时不能可变借用

这条规则消除了一个在并发编程中臭名昭著的问题:数据竞争(data race)。当两个线程同时访问同一块内存,且至少有一个在写入,就可能出现数据竞争。Rust的借用规则在编译时就阻止了这种情况。

借用检查器

这些规则的执行者叫做"借用检查器"(borrow checker)。它在编译阶段分析代码的控制流,追踪每个引用的生命周期。

早期版本的Rust使用"词法作用域生命周期"——引用的有效期由它在代码中的位置决定。这导致了一些令人沮丧的情况:明明代码逻辑上没问题,但借用检查器就是不通过。

2018年,Rust引入了"非词法生命周期"(Non-Lexical Lifetimes, NLL)。借用检查器开始基于实际的控制流图进行分析,而不仅仅是代码的词法结构。一个引用只要在最后一次使用之后就不再被视为"存活",即使它所在的作用域还没结束。

这个改进让Rust变得更易用,同时保持了安全保证。

1000倍的差距

2025年11月,Google安全博客发布了一组令人瞩目的数据。

Android操作系统的内存安全漏洞数量,从2019年的223个,下降到2024年的不到50个。这是该平台历史上第一次,内存安全漏洞占总漏洞的比例降至20%以下。

更令人惊讶的是漏洞密度的对比。Android团队统计:

  • C/C++代码:约每100万行代码产生1000个内存安全漏洞
  • Rust代码:500万行代码中仅发现1个潜在的内存安全漏洞,密度约为每100万行0.2个

1000倍的差距。

这不是魔法。Android团队发现,Rust代码的回滚率(因严重问题被撤回的比例)比C++低4倍,代码审查时间少25%。更安全的代码,同时也是更高效的代码——这颠覆了"安全需要牺牲效率"的传统观念。

unsafe的边界

Rust并非万能。约19%的crate使用了unsafe关键字——这是一个显式声明,告诉编译器"我知道我在做什么,请暂时关闭安全检查"。

unsafe块内可以执行原始指针操作、调用C函数、访问可变静态变量。这些操作是必要的——操作系统内核需要与硬件交互,需要调用现有的C库。

unsafe不是放弃安全。Rust社区发展出了一套"安全封装"的实践:将unsafe代码隔离在最小范围内,用安全的API封装它们,并在代码注释中详细说明安全保证的理由。

Google的数据显示,即使是unsafe Rust代码,其漏洞密度也远低于等量的C/C++代码。原因可能在于:使用unsafe是一种显式的、有意识的行为,程序员在写这些代码时会格外小心;同时,Rust的工具链(如Miri解释器)可以帮助验证unsafe代码的正确性。

Linux内核的接纳

将Rust引入Linux内核的旅程始于2020年,但真正的里程碑在2022年。

当年10月,Linus Torvalds本人批准了一个pull request,将Rust支持合并到Linux 6.1。这是Linux内核30多年历史上,第一次接受除C和汇编之外的语言作为一级公民。

Torvalds的态度经历了明显的转变。2020年,他在开源峰会上表示Rust"可能会进入内核"。2022年,他说"除非发生意外,Rust会在6.1中"。到了2024年,他在接受采访时说:“如果有维护者反对Rust,我会介入。”

但这个过程并不顺利。

文化和技术的碰撞

2024年8月,Rust for Linux项目的核心维护者之一Wedson Almeida Filho宣布退出。他在给内核邮件列表的信中写道,自己"厌倦了处理非技术性的胡扯"。

争议的核心在于:Linux内核有着庞大的C代码库和深厚的C文化。一些维护者对Rust持怀疑态度,认为它会增加复杂性、分裂社区。有人质疑Rust的编译器稳定性——内核需要支持多种架构和编译器版本,而Rust目前依赖一些不稳定特性。

另一方面的担忧是生态系统:C有着40多年的工具链积累,Rust在这方面还有差距。调试、性能分析、静态分析工具都需要时间成熟。

Torvalds本人试图平衡这些声音。他在2024年的内核维护者峰会上表示,理解老一辈C程序员的顾虑,但强调Rust的价值已被证明。“我们不会一夜之间重写内核,“他说,“但新的代码应该考虑使用Rust。”

驱动的现实

尽管争议,Rust已经在Linux内核中找到了位置。截至2024年底:

  • rnull:一个null设备的替代实现
  • ASIX AX88772A和Realtek网络PHY驱动
  • Android Binder IPC驱动
  • 只读ext2文件系统
  • Nova项目:计划用Rust重写NVIDIA开源驱动

正在开发中的还有:QR码恐慌处理器、NVMe驱动、Asahi Linux的Apple GPU驱动。

这些项目有一个共同点:它们是相对独立的模块,有清晰的边界,适合用Rust进行实验。内核社区采取了渐进策略——不是重写现有代码,而是在新代码中验证Rust的价值。

政府的背书

2024年2月,美国白宫科技政策办公室发布了一份技术报告,标题是《回归基石:迈向内存安全的未来》。

报告开门见山:内存安全漏洞是"最普遍的已披露软件漏洞类型”。报告列举了符合内存安全标准的语言:Python、Java、C#、Go、Swift、Rust……

这是美国政府第一次正式建议软件开发者放弃C和C++。

同年,NSA和CISA联合发布了网络安全信息表,详细分析了内存安全语言的采用策略。报告指出,在浏览器和内核中,约60-70%的漏洞源于内存安全问题。

这些政府报告不是无的放矢。它们反映了一个共识:在关键基础设施领域,内存安全漏洞已经从"技术问题"上升为"国家安全问题”。

安全关键系统的门槛

汽车、航空、医疗设备——这些领域有着严格的安全标准。ISO 26262(汽车)、IEC 61508(工业控制)、IEC 62304(医疗设备)定义了不同级别的安全完整性等级。

Rust正在进入这些领域。Ferrous Systems公司开发了Ferrocene,一个符合ISO 26262标准的Rust工具链,使Rust可以用于认证的安全关键应用。欧洲航天局(ESA)已经开始评估Rust在航天系统中的应用。

2026年1月,Rust官方博客发表文章《在安全关键领域发布Rust需要什么》,详细讨论了各行业标准对编程语言的要求。文章指出,Rust的类型系统和所有权模型天然符合安全关键系统的许多要求。

不是没有代价

如果Rust如此完美,为什么不是所有人都在用它?

学习曲线

Rust的学习曲线是真实的。2024年的Rust社区调查显示,31%的受访者认为"认知难度"是不使用Rust的主要原因。

所有权和借用需要一种不同的思维方式。在C++中,你可以在任何时候访问任何指针(如果它还活着);在Rust中,编译器会强迫你思考数据的生命周期。这种思考是额外的认知负担,但也是安全的来源。

一个常见的抱怨是"与借用检查器搏斗"——代码逻辑上是对的,但编译器就是不让过。有经验的Rust开发者说,这种感觉会随着时间消失,取而代之的是对"内存布局"的直觉把握。

编译时间

Rust的编译速度是另一个痛点。严格的编译时检查意味着编译器要做更多工作。大型Rust项目的编译时间可能比等量的C++代码更长。

社区正在努力改进这个问题。并行前端编译、增量编译、更快的链接器——这些优化正在逐步推进。但编译速度仍然是被调查者最常提到的生产力障碍。

生态系统

C和C++有着40多年的生态系统积累。你需要的功能,几乎都能找到成熟的库。Rust的crates.io已经有超过14万个包,但覆盖面和成熟度仍有差距。

特别是嵌入式系统和特定硬件领域,C的统治地位仍然稳固。Rust正在追赶,但改变需要时间。

两种哲学的对峙

Rust的成功引发了一个更深层的问题:为什么不是让C++变得更安全?

这实际上正在发生。C++社区正在推动"安全特性"的添加,如边界检查、生命周期分析工具。Clang编译器已经实现了类似Rust的生命周期注解实验性支持。

但Rust支持者认为,这不够。安全必须是默认的,而不是可选的附加组件。一个程序员可以在90%的代码中小心翼翼,但那10%的疏忽就可能导致灾难。

C++的历史包袱太重。它不能破坏数以亿计的现有代码。任何安全改进都必须是向后兼容的,这限制了激进变革的可能性。

Rust没有这个包袱。它从零开始设计,让安全成为第一性原理。这是一种哲学选择:强迫程序员在编译时正确,而不是在运行时崩溃。

还在继续的故事

2025年12月,Linux内核维护者峰会做出了历史性的决定:Rust正式成为内核的核心语言,不再被标记为"实验性"。

这个决定的象征意义大于实际影响——实际工作中,Rust代码在内核中的占比仍然很小。但它传递了一个信号:Linux社区认为Rust是未来的一部分。

同月,微软宣布计划在2030年前用Rust重写Windows内核和Azure基础设施的关键组件。Android平台上的Rust代码量已经与C++相当。Dropbox用Rust重写了同步引擎,Discord用Rust替换了Go代码后性能提升10倍。

Rust用户数量从2022年的200万增长到2024年的400万。在Stack Overflow的开发者调查中,Rust连续七年被评为"最受喜爱的编程语言"。

但这些数字背后,是更深层的趋势:行业正在重新评估"效率"的定义。

过去,效率意味着执行速度和内存占用。今天,效率还包括开发效率、安全效率、维护效率。Rust在第一项上与C++相当,在后三项上展现出优势。

这不是说Rust会取代C++。数以亿计的C++代码将继续运行数十年。但新的系统代码,尤其是在安全敏感领域,会越来越多地使用内存安全的语言。

回到那个21楼的电梯。Graydon Hoare在2006年爬楼梯时的愤怒,催生了一门改变编程世界格局的语言。他后来淡出了Rust项目,把接力棒交给了社区。

2015年Rust 1.0发布时,他在邮件列表里写了一句话:“大多数编程语言,都默默死在角落里。”

Rust没有。它用十七年的时间,从一个人的愤怒,走到了操作系统内核的中心。


参考资料

  1. Microsoft Security Response Center. “A Proactive Approach to More Secure Code.” 2019.
  2. Google Security Blog. “Rust in Android: move fast and fix things.” November 2025.
  3. The Rust Foundation. “Unsafe Rust in the Wild: Notes on the Current State of Unsafe Rust.” May 2024.
  4. Wikipedia. “Rust for Linux.” Accessed 2024.
  5. MIT Technology Review. “How Rust went from a side project to the world’s most-loved language.” February 2023.
  6. The Register. “Rust for Linux maintainer steps down in frustration.” September 2024.
  7. White House Office of the National Cyber Director. “Back to the Building Blocks: A Path Toward Secure and Trustworthy Software.” February 2024.
  8. NSA & CISA. “Software Memory Safety.” November 2022.
  9. Rust Blog. “2024 State of Rust Survey Results.” February 2025.
  10. Rust Blog. “What does it take to ship Rust in safety-critical?” January 2026.
  11. Phoronix. “Linux Kernel Highlights For 2025: Schedulers, Rust & Torvalds.” December 2025.
  12. Ars Technica. “As the Kernel Turns: Rust in Linux saga reaches the ‘Linus in all his glory’ stage.” February 2025.