主题
字号
CHAPTER 06 ≈ 16 MIN READ

2026 年的 Rust 现状——它在哪里，走向哪里

6.1 站在2026年看Rust

写这一章的时候是2026年，Rust 1.0发布已经过了十一年。十一年对一门编程语言来说不算长，但Rust的发展速度远超一般语言的成熟曲线。

从技术上说，Rust核心语言已经相当稳定，大的变化主要集中在标准库的完善、异步编程模型的成熟、以及编译速度的持续优化。从生态上说，crates.io（Rust的包注册中心）上的crate数量已经超过15万，常见的应用场景基本都有可用的库。

下面我们逐一看2026年各个战场的现状。

6.2 Linux内核：已经落地，正在扩展

6.2.1 从Linux 6.1到现在

Linux 6.1（2022年12月）是Rust正式进入Linux主线的起点，但那时候的Rust支持非常基础——只是基础设施，没有什么实际的内核代码是用Rust写的。

之后几个版本里，Rust的基础设施逐步完善。到2024-2025年，第一批用Rust写的实际内核驱动开始合并进主线。其中最值得关注的是Nova项目——用Rust重写NVIDIA GPU驱动的初始实现（不是完整驱动，是一个从零开始的开源替代，和NVIDIA的私有驱动独立）。

6.2.2 内核Rust的现状和争议

进展不如乐观者预期，争议也没有消失。

有几位内核老手明确表示不满，主要是对"Rust代码加进来但维护责任不清晰"的担忧。有一位内核维护者甚至在2024年以"对Rust支持不满"为由退出了维护团队，引发了较大讨论。

但反过来，有Google、ARM等公司的工程师持续提交Rust相关的补丁，内核Rust基础设施在每个版本都有进步。Linus自己表示"Rust在内核里的进展比我预期的慢，但这是正常的，内核不应该激进"。

内核里的Rust目前还是少数派，核心代码全部是C，Rust代码只存在于一些新的驱动和实验性的基础设施里。这个情况在未来五年内大概率不会有根本性变化——内核保守主义是有道理的，稳定性比引入新技术重要。

6.2.3 真正的影响：示范效应

Linux内核引入Rust的最大意义，在前面提到过，是示范效应。它让很多保守的组织觉得"连Linux内核都用了，我们也可以考虑"。这种心理效应难以量化，但真实存在。

6.3 Windows：微软的Rust化进程

6.3.1 已经完成的部分

微软在Windows里引入Rust的速度比Linux快，原因是微软可以内部决策，不需要开放式社区的共识。

Windows内核（ntoskrnl.exe）的部分模块已经有Rust代码，字体渲染引擎、DNS客户端库的部分实现被重写了。最重要的是，Windows驱动程序框架（WDF）提供了Rust绑定，第三方开发者现在可以用Rust写Windows驱动了。

6.3.2 Rust for Windows的开发者工具

微软维护了windows这个Rust crate，它提供了对Windows API的完整访问，包括Win32、WinRT、COM接口。这是目前体积最大的单一Rust crate之一，自动从Windows SDK生成绑定。

// 用Rust调用Windows API的示例
use windows::Win32::UI::WindowsAndMessaging::MessageBoxW;
use windows::core::w;

fn main() {
    unsafe {
        MessageBoxW(None, w!("Hello from Rust!"), w!("Demo"), Default::default());
    }
}

这段代码需要unsafe因为Win32 API本身没有安全保证，但这比用C写同样的代码要方便很多——windows crate自动处理了类型转换和调用约定。

6.3.3 Azure基础设施

Azure（微软云）后端的很多新组件是Rust写的，尤其是需要高性能和高可靠性的那些，比如部分存储服务的内部组件。微软没有公开太多细节，但从他们在Rust工具链上的投入和招聘方向可以看出方向。

6.4 Android和Chrome：Google的Rust版图

6.4.1 Android里的150万行Rust代码

Google在2021年开始向Android添加Rust代码，到2023年已经有约150万行Rust。这些代码主要集中在：

Google发布的数据：在Android里，Rust代码的内存安全漏洞密度（每行代码的漏洞数）显著低于C/C++代码。这个数据被引用了很多次，成为"Rust确实有效果"的实证。

6.4.2 Chromium里的Rust

Chromium（Chrome的基础）从2023年开始允许引入第三方Rust库，之后逐步扩展到允许在Chromium自己的代码里写Rust。这个过程很谨慎，但方向是确定的。

Chrome的一些安全性敏感组件（URL解析、媒体编解码接口等）有Rust实现。Chromium项目文档里现在有专门的Rust指南，解释什么情况下应该优先用Rust。

6.5 2026年的明星项目

6.5.1 Zed：编辑器领域的标杆

Zed在2024年开源（之前是闭源产品），开源之后社区贡献爆发，扩展生态快速成长。2025年Zed加入了AI代码补全和对话功能，但保持了性能优先的设计原则——AI功能用流式传输，不阻塞编辑器主线程。

Zed目前仍然主要是macOS和Linux用户的选择，Windows版本2024年进入测试，功能比较完整但性能优化还在进行中。作为一个从头Rust实现的编辑器，它的代码库本身就是一个很好的Rust大型项目学习材料。

6.5.2 uv：Python工具链的颠覆者

uv（由Astral开发，同一家公司也做了Ruff——Python的极速linter）在2024年发布，迅速成为Python包管理领域的热门话题。它用Rust实现了pip兼容的包解析和安装，速度比pip快10-100倍，这不是夸张，是可以在任何机器上复现的基准测试结果。

uv正在试图统一Python的依赖管理工具链（pip、pip-tools、virtualenv、poetry……Python依赖管理的历史是一段痛史），有没有成功还要看后续，但它的出现证明了一点：即使是Python生态，也在用Rust解决性能痛点。

6.5.3 Pingora：Cloudflare的NGINX替代

Cloudflare的Pingora在2024年开源，它是Cloudflare内部替换NGINX的HTTP代理库，处理的流量规模是全球前几位的CDN级别。Pingora的设计目标是支持每秒数千万请求，同时内存使用比原来的NGINX架构低很多。

Pingora的架构很有意思，它用Rust的异步运行时（tokio）处理并发，用共享连接池代替NGINX的多进程模型，这使得同等流量下的内存消耗大大降低（Cloudflare报告减少了约75%）。

6.5.4 Deno和Bun：JS运行时的Rust渗透

Deno（Node.js创始人Ryan Dahl的新项目）用Rust写了其核心运行时组件，JavaScript引擎本身用的是V8，但围绕V8的所有"胶水"代码是Rust。Deno的文件系统、网络、权限系统都是Rust实现。

Bun更进一步，用Zig写了JavaScript引擎（JavaScriptCore），但核心的包管理器和模块解析有Rust参与。Bun 1.0在2023年发布，在Node.js兼容性和速度上都有很好的表现。

这两个项目展示了一个有趣的模式：新一代开发者工具正在用Rust（或Zig等系统语言）替换传统上用C/C++写的组件，追求兼顾安全和性能。

6.5.5 Rust在AI基础设施里

这一点和尾声有交叉，先在这里铺垫：Rust在AI基础设施里的存在是间接的但真实的。

HuggingFace的tokenizers库——几乎所有NLP模型训练和推理都要用到的分词器——核心逻辑是Rust写的，Python是它的绑定层。这个选择让tokenizers的速度比纯Python实现快几十倍，对大规模训练数据预处理来说差距非常明显。

PyTorch的部分算子在向Rust迁移，TensorRT（NVIDIA的推理优化库）的周边工具有Rust实现。AI编译器领域（MLIR、Triton等）也有Rust的参与。

Rust不会成为AI建模语言——那是Python的地盘，根深蒂固。但在"AI基础设施的底层"，Rust正在占据越来越多的位置。

6.6 Rust基金会和社区生态

6.6.1 Rust基金会

2021年，Rust基金会正式成立，Mozilla把Rust的相关商标和资产移交给基金会。创始赞助商包括微软、Google、AWS、华为、Facebook（Meta）。这标志着Rust的治理从"Mozilla的项目"变成了"行业共同体的项目"。

基金会的主要工作是：资助Rust工具链的基础设施（crates.io的服务器费用、持续集成等）、支持核心团队成员的工作、管理商标许可、组织RustConf等社区活动。

核心语言的设计决策仍然由RFC（Request For Comments）流程完成，任何人都可以提提案，核心团队负责审核，这保证了Rust的开放性。

6.6.2 crates.io生态

crates.io是Rust的包注册中心，类比Python的PyPI、JavaScript的npm。截至2026年，crates.io上有超过16万个crate，每周下载量超过10亿次。

这个数字在数量上不如npm（几百万个包），但质量上Rust生态的特点是：关键领域有几个高质量、被广泛使用的库，而不是几十个质量参差的选项。比如：

这种"有主流、有竞争"的格局比Python或JS更清晰，新手面对的"选择困难症"相对小一些。

6.6.3 Rust的版次（Edition）系统

Rust有一个聪明的版本管理机制叫Edition（版次）。每隔几年发一个Edition（目前有2015、2018、2021），在新Edition里可以做不向后兼容的语法改动，但旧代码可以在同一个编译器下继续用旧Edition编译。不同Edition的代码可以在同一个项目里共存（crate级别的版次设定）。

这个设计解决了语言演进和向后兼容之间的矛盾——Python 2到Python 3的痛苦就是没有这种机制。Rust 2024 Edition在2024年末发布，做了一些小的语法改进，迁移成本很低。

6.7 下一个十年：会成为下一个C吗

6.7.1 "下一个C"是一个很高的标准

C的地位不只是因为它快，而是因为：几乎任何系统都能运行C代码，几乎任何语言都能和C互操作。Python可以调用C库，Java可以通过JNI调用C，Go可以通过cgo调用C，几乎所有语言都把"C ABI兼容"作为FFI的基础。

C这个地位是几十年历史积累的，不可能被短期替代。更现实的问题是：Rust能成为新项目的默认选择吗？

6.7.2 乐观的理由

行业趋势是真实的。政府监管（美国的ONCD报告、欧盟的网络弹性法案对安全要求的提升）在把软件行业往"内存安全语言"推。这个力量是外部的，不依赖于Rust社区自己的布道。

替代选项有限。想要同时满足"无GC"、"接近C性能"、"内存安全"这三个条件的语言，2026年可以认真考虑的只有Rust。Go没有做到接近C的性能（有GC），Zig没有Rust那样的安全保证体系（更接近"更好的C"），Ada太小众且有历史包袱。Rust在这个生态位上基本是唯一选项。

开发者偏好是可持续的。连续多年的"最受喜爱"不是偶然，用过Rust的工程师愿意推荐它、愿意在新项目里用它。这种自发的传播是最持久的增长引擎。

6.7.3 悲观的理由

学习曲线没有明显降低。Rust努力改善错误信息、改善文档，但所有权系统本质上是一个新的思维模型，这个门槛没有被完全消除。很多组织无法接受让工程师花几个月时间真正掌握Rust。

遗留代码不会消失。世界上大量的系统代码是C/C++写的，这些代码不会因为Rust存在就重写。重写的成本和风险在很多场景下超过了安全收益。Rust更可能是"新项目的选择"，而不是"旧项目的替代"。

AI辅助编程改变了游戏规则。GitHub Copilot、Claude等AI工具大大降低了写Python、JS等动态语言的门槛，但对Rust的帮助相对有限——Rust的核心难点（所有权、生命周期）需要工程师真正理解，AI生成的代码在这里的错误率比动态语言更高。如果AI把"快速原型"的效率再提高一倍，Rust相对于Python的劣势会进一步放大。

6.7.4 Claude的猜测

不会成为"下一个C"，但会成为"新一代系统软件的标准语言选项之一"。

更具体地说：十年后的图景可能是——操作系统新模块、驱动程序、CLI工具、高性能网络服务、WebAssembly的首选语言就是Rust；老的C/C++代码库继续存在，但新建的同类项目会优先考虑Rust；AI/ML的计算层继续在C/CUDA，但工具链层越来越多是Rust；业务后端、数据科学、脚本领域，Python/Go/JS继续统治。

这个图景里的Rust，比今天的Rust覆盖面要大，但远没有C那种无处不在的地位。这是一个现实的、值得期待的未来。