Rust 编程语言评测：值得学吗？

去问两位有经验的 Rust 开发者，学 Rust 是否值得，你可能会得到完全相反的答案。一位可能说它对自己的职业毫无帮助；另一位可能说这是自己做过的最好的技术决定之一。两人都可能是对的。

“Rust 值不值得学”这个问题的真正症结就在这个矛盾里，这也是为什么一句笼统的“值得”对你毫无用处。Rust 是一门编译型语言，它的安全子集在编译期强制执行内存安全规则，运行时不需要垃圾回收器。

所以我会给出明确的答案，说清它取决于什么条件，并告诉你这个条件要付出什么代价。

简短版本

如果你要构建的是长期存在的东西，而让编译器帮你拦下一整类 bug 值得为之付出代价，那 Rust 就值得学。如果你这个月就要交付一个 CRUD 应用、正在入门编程，或者在数招聘岗位，那它就不适合你。 评分：5 分中的 4 分，扣掉的一分是它在回本之前的成本。

• 你得到的： 在安全 Rust 中，所有权和借用规则会把 use-after-free、重复释放、无效引用和数据竞争这类 bug 变成编译错误，而不是生产事故。这就是它全部的卖点，而且是个好卖点。
• 你付出的： 编译器要求你把现在所用语言默默替你做的内存决策明确写出来，刚开始时会觉得是工具在故意刁难。
• 长期存续的问题已经有定论。 内核维护者在 2025 年 12 月的 Maintainers Summit 上宣布结束 Rust 实验，“实验性”标签在 Linux 7.0 中被移除。
• 流行度的问题还没有定论，而且那是另一个问题。 Rust 在 TIOBE 2026 年 9 月的指数中排名 #10，一年前是 #18。
• 我测试的 Rust 服务，编译所需内存远多于运行所需：构建时峰值接近 1 GB，运行时空闲约 3.5 MB。
• 适合你，如果 你已经在用另一门语言交付产品，正在构建内存 bug 代价很高的东西，或者你的工作贴近系统软件。 不适合你，如果 你赶着截止日期、从零开始，或者在挑岗位最多的语言。

本评测的做法： 这里的构建和运行数据都是我自己测的。我安装了 Rust 1.98.1，写了一个小型 Axum Web 服务，测量了编译它和运行它各需要多少资源。测试在沙箱容器中进行，而非专用硬件，而且只有一个项目，所以请把这些数字当作一个数据点，而不是定律。其余内容都来自一手或权威来源：内核补丁及 LWN 对它的报道、Google 的 Android 安全博文、TIOBE 自己的指数（四月的评论引自 Slashdot 的记录）、Phoronix 关于 Linux 7.0 合并窗口的报道、Linux 内核关于 Binder 漏洞的 CVE 记录、Canonical 的官方声明，以及 2025 年 Stack Overflow 调查。我读过内核补丁。我没有审计内核中的 Rust 代码。而且我并没有写了很多年 Rust，所以本评测中评判语言本身的部分，是在参考那些写了多年的从业者的观点，并注明了他们的名字。

编译器为你换来了什么

在 Rust 里把同一个 vector 的可变引用交给两个线程，代码就无法编译。不是警告。也不是赶工时可以关掉的 lint。它根本构建不了。这种拒绝正是你在安全 Rust 中买到的东西：use-after-free、重复释放、无效引用和数据竞争 bug 被推到编译错误里，而不是变成生产事故。Rust 的逃生舱（unsafe）可以绕过其中部分保证，所以这并不是对每个 Rust 代码库的绝对承诺。

所有权指的是每个值都恰好有一个负责释放它的所有者。借用指的是你可以把引用借出去，但编译器会追踪它们的生命周期，不允许引用活得比它指向的东西更久，也不允许可变借用与任何其他借用同时存在。在安全 Rust 中，use-after-free、重复释放、无效引用和数据竞争 bug 会在程序运行前就被所有权和类型系统捕获。

没有垃圾回收器，这是这笔交易的另一半。因为所有权已经说明了谁在什么时候释放什么，运行时就不需要追踪你的堆。你交付的二进制里没有回收器，也不会有需要费心调优的停顿时间。

代价和保证出现在同一个地方。你现在的语言悄悄替你做的每一个内存决策，Rust 都要求你明确写下来：这个归谁所有，那个引用活多久，还有没有别的东西能看到它，它会不会跨越线程边界。编译器不是在刁难你。它是拒绝去猜。

所以说：这就是人们愿意付出 Rust 所要求代价的原因，而我认为它站得住脚。如果它消灭的那类 bug 不是你担心的那类，那么本评测剩下的内容大概也改变不了你的想法。

Rust 还是实验性的吗，还是已经成为生产基础设施？

它在 2025 年 12 月不再是实验性的，而结束这场实验的正是内核维护者自己。在 2025 年的 Maintainers Summit 上，他们得出结论：无论在技术上还是在社区层面，Rust 都已在内核中证明了自己的价值。LWN 的 Jonathan Corbet 在 2025 年 12 月 10 日报道了这一共识：内核中的 Rust 不再是实验性的.

Rust 于 2022 年在 v6.1 进入 Linux 主线，目的正是进行这场实验。Miguel Ojeda 移除该标签的补丁在峰会三天后提交，并进入了 Linux 7.0 合并窗口.

“但实验已经结束，也就是说，Rust 会留下来。”

Miguel Ojeda，“rust: conclude the Rust experiment”，LKML，2025 年 12 月 13 日

另外，而且更早：Google 用 Rust 重写的 Android Binder 驱动，也就是 Android 各进程（时刻都在）用来通信的 IPC 层， 已合入 Linux 6.18，该版本于 2025 年 11 月 30 日发布。请把这个里程碑和峰会共识分开看。这一次是一家公司把正在出货的产品押在了内核 Rust 上，而不是一群维护者为一个想法背书。此后，内核 Rust 已经出现了第一个 CVE： CVE-2025-68260，这是同一个 Binder 驱动中的竞态条件，由 Greg Kroah-Hartman 于 2025 年 12 月 16 日公布，在 6.18 中引入，在 6.18.1 中修复。最初的报道集中在崩溃上，但 Linux 内核 CVE 团队后来的评分将 CVE-2025-68260 定为 7.8（High），并描述了一条通过内核内存破坏实现本地提权的路径。同一个驱动（rust_binder）此后又陆续出现了更多 CVE。

在 Android 上，证据有了具体数字。Google 的安全博客在 2022 年 12 月表示， 没有发现任何内存安全漏洞 出现在 Android 的 Rust 代码中，而当时 AOSP 中约有 150 万行 Rust，约占 Android 13 全部新增原生代码的 21%。这是 2022 年的声明，范围也是 2022 年。Google 后来的博文给出了更长的趋势：内存安全问题 在 2019 年占 Android 漏洞的 76% 而到 2024 年降至 24%，原始数量 从 220 多个降至预计的 36 个。这些数字只有放在它们所取代的基线面前才有意义，而那条基线是由非常优秀的工程师、借助非常好的工具写出的 C 和 C++。

还有两个较小的信号指向同一方向。 Apple AGX GPU 驱动 在 Asahi Linux 中是用 Rust 写的，由 Asahi Linux 项目通过逆向工程开发，而非 Apple 编写。 Canonical 的 rust-coreutils 进展更新 指出，Ubuntu 26.04 LTS 的大多数工具采用 rust-coreutils 0.8.0。有三个工具仍保留 GNU coreutils（cp, mv, rm），因为截至 2026 年 4 月 22 日仍有八个 TOCTOU 问题未解决；Canonical 计划在 26.10 中替换剩余的工具。

这是我打分最高的一项，原因在于其中涉及的承诺性质。内核维护者不会撤回已经下了结论的实验，Google 不会推倒这种规模的重写，Canonical 也不会为了试试看就把重写的 coreutils 放进 LTS。无论 Rust 的人气如何变化，总得有人在未来很多年里维护这些代码。

Rust 凉了吗，还是只是增长趋缓？

没有。Rust 在 2026 年 1 月追平了自己在 TIOBE 上的历史最佳排名 #13。三个月后它回落到 #16，TIOBE 的 CEO Paul Jansen 在 2026 年 4 月写道（Slashdot 当时引用了这段评论），Rust 的人气增长“似乎正在趋于平稳”，而进入前 10“现在看起来比以前更遥远”。

他描述的是 Rust 在他自己的指数上达到 有史以来的最高排名 （它在 2024 年 7 月首次达到这一位置），然后又跌了回去。

TIOBE 2026 年 9 月的指数 把 Rust 排在 #10，一年前是 #18，也超过了 TIOBE 在 1 月称为其历史最高的 #13。

我的看法：平台期是真实的。但它是一个气穴，不是天花板。这比任何一方的说法都更准确，因为“Rust 停滞了”现在已经错了，而“Rust 只会一路上涨”从来就不对。

这个提醒是双向的，Slashdot 的报道当时就提出过： 排名会不会只是在波动 而已，原因是搜索引擎结果逐月的噪声，而这正是该指数统计的东西？如果一个季度下滑三位只是 Rust 放缓的薄弱证据，那么上升六位同样只是它在胜出的薄弱证据。把它当作天气，而不是气候。

关于开发者情感，更有力的信号是 Stack Overflow 调查，Rust 再次成为最受推崇的 编程语言，2025 年的比例为 72%：即过去一年用过它、并且想继续用的人。这是继续使用的意愿，而不是采用率；如果你想判断自己会不会乐于坚持用这门语言，它比单纯的流行度更有参考价值。

势头并不明朗，我给它的权重低于上面说的长期存续，因为你投资的不是一个排名。

学习 Rust 要付出什么

成本来得早，而且一次性全部压过来。Python、Java 或 C# 乐于运行的代码会被一次又一次拒绝，理由在你理解所有权模型之前显得莫名其妙，而且没有办法推迟。你可以在没完全搞懂 ORM 的情况下先交付再说，但借用检查器不能这样糊弄过去。

让我意外的是下面这点，而且它和你的预期正好相反。在 r/rust 的“Struggling to learn Rust”帖子里，最受认可的回复把问题重新定义为不熟悉，而不是难，整个帖子也指出，从垃圾回收语言转过来的资深开发者反而更吃力。u/Voxelman 说得很直白： “Rust 并不难。它只是不同。” 在同一个帖子里，他们讲了自己的入门路径：先是 C64 Basic，然后是一系列命令式语言，第一次接触 Rust 时“一点都不 WOW”，因为摆脱旧习惯花了不少时间。

这就是账单的样子。如果你写了八年 Python，你要做的不是学一套规则，而是放弃一套关于“谁来替你收拾”的假设。懂得少的人，要忘掉的也少。

那个帖子里还反复出现另一种模式，它会把顺序上的失误变成信心问题：人们卡住的不是 Rust，而是选 Web 框架，在所有权还没真正理解之前就试图通过 Axum 或 Actix 来学这门语言。正如 u/jmartin2683 所说，这 “就像通过学 rails 来学 ruby。”

我认为大多数关于成本的警告都指错了方向。要预留的是持续的练习，而不是一个周末；也别把早期的挫败当成对你能力的判决。

Rust 构建所需的机器比运行所需的更大

这是我没料到的发现：构建这个 Rust 项目所需的内存比运行它多出几个数量级。我构建了一个小型 Axum 服务（Tokio 启用 full 特性集，加上 serde、serde_json、tower，一个 JSON 路由，依赖树中约 60 个 crate），使用 rustc 和 cargo 1.98.1，release 配置中设置 strip = true 然后从干净状态构建了两次：

# constrained: one compile job at a time
cargo build --release --jobs 1
# unconstrained: default parallelism, 4 vCPUs available
cargo build --release

限制为一个编译任务时（--jobs 1），cargo、rustc 和链接器的内存峰值在 464 MB 到 527 MB 之间，取决于采用我两种测量方法中的哪一种（我之所以测两次，是因为第一个数字看起来太整齐了），耗时 113 秒。在四个 vCPU 上使用默认并行度时，内存峰值大约翻倍，达到约 1 GB，构建约 35 秒完成。这里的变量是并行度，而不是项目。任务越多，同时驻留的 rustc 进程就越多，这就是为什么编译器是少数几种会一连好几分钟 乐于吃掉你给它的每一个核心 的工作负载之一。

最终程序 strip 后为 1.3 MB，空闲时内存占用约 3.3 到 3.6 MB。

在默认并行度下，编译所需内存是运行的两三百倍；限制为一个任务时仍然远超一百倍。如果按 Rust 服务在生产中的需求来配置服务器，你可能得到一台连它都构建不了的机器，而且失败方式并不是干净的报错：要么是 OOM killer 在构建中途杀掉 rustc，要么是编译器疯狂读写 swap 长达二十分钟。有两种可行的办法。一是在有余量的地方构建，然后交付二进制，这和 单独准备一台构建机 来处理繁重 Docker 任务是同一个模式。二是在这台机器上构建并给它足够空间：对于这种形态的服务，几 GB RAM 加两个 vCPU 就很宽裕。如果不够，退路是 --jobs 1 （没错，会更慢；这就是取舍）。

如果你工作用的机器没有这么多余量，我们的 自管理 Linux VPS 提供 root 权限，可按小时或按月计费，给你一个放置构建、用完即可退还的地方；不过它仍然是一台需要你自己运维的服务器，而不是会自己运维的服务器。

一个项目，一种形态，一台机器。这台机器是共享的沙箱容器，不是专用服务器，可用内存约 2 GB，所以不受限制时的峰值比在更大的机器上更接近上限。这些并不是普适常数：如果你的依赖树是它的四倍大，或者 release 配置开启了链接时优化，数字会不一样。更大的依赖树、链接时优化以及大量使用泛型的代码都会推高构建内存，所以别把我的测量结果当作普适的上限。

我会把这一点归到“你怎么工作”，而不是“你要不要学这门语言”。在撞上它之前先了解它。

谁应该学 Rust

有三种情况我会建议你花这个时间：内存 bug 代价高昂的长期软件、贴近操作系统的工作，以及想要体验和编译器较劲会如何改变你对内存的思考。每一种都有让这段时间得到回报的理由。

你已经在用另一门语言交付产品，并且正在构建一个内存 bug 代价高昂的长期项目。 一个必须持续在线的服务。一个其他团队依赖的库。任何 use-after-free 意味着一次事故复盘、而不是终端里一段堆栈跟踪的东西。整套保证正是为这种情况打造的，前期付出的成本会在你所构建东西的整个生命周期里摊销。

你的工作贴近或深入系统软件。 驱动、设备开发、基础系统工具、嵌入式，任何位于操作系统之下而非之上的东西。业界在这里做出的投入是别处没有的，内存安全方面的证据也在这里最有力。

你想要那份附带收获。 那个 r/rust 帖子里的两位评论者，对 Rust 的职业价值看法完全相反，却在这一点上得出了同样的结论。 u/tyler_church，说它对职业毫无影响，但仍然承认它“也许对我用其他语言写其他程序的方式有些微妙的影响”。 u/SirKastic23，靠写 Rust 拿工资已经两年，说它以自己从没预料到的方式拓宽了编程技能。这只是两个人，不是一项研究，但这是即使你从未以写 Rust 为职业也依然存在的回报：思维方式的改变，而不是简历上的一行字。

谁不应该学 Rust

有三种情况，这些时间最好花在别处：你这个月有截止日期，你还在入门编程，或者你按招聘岗位的提及次数来挑语言。第三种是人们问得最多的。

你这个月要交付一个 CRUD 应用或原型。 对于必须在周五前做出来的工作，Rust 来的时机恰恰最糟糕。如果你想要一门构建快、采用垃圾回收内存管理的编译型语言，又不需要 Rust 基于所有权的保证，那么显而易见的替代选择是 Go。

你还在入门编程。 这一点在以写 Rust 为生的人之间确实存在分歧，r/rust 帖子里的争论两个方向都有，所以我的立场是：无论硬币落在哪一面，递给初学者一次抛硬币都是糟糕的建议。先在更宽容的环境里学会机器是怎么工作的，然后再回来，让编译器帮你收紧。

你按招聘岗位的提及次数来挑语言。 这里我不会给出数字，因为我找不到一个能追溯到我愿意为之辩护的来源的 Rust 薪资或岗位数据。u/crusoe 在那个 r/rust 帖子里描述的是一个岗位更少、更专业化的市场。那只是一个帖子里的一位评论者，不是劳动力市场数据，所以我不会把它变成“Rust 岗位普遍稀缺”的论断。如果岗位数量是你的决定因素，在选择语言之前先查看目标市场当前的招聘信息。

常见问题

Rust 免费吗？

是的。这门语言及其官方项目 通常采用双重许可 授权，分别为 MIT 许可证和 Apache License 2.0，工具链可以通过 rustup 免费安装。没有付费档位，也没有需要购买的商业许可证。

学会 Rust 需要多长时间？

如果你已经会编程，语法通常是最容易的部分。所有权和借用需要更长时间，因为它们会改变你对内存的思考方式；生命周期和异步 Rust 之后还会再加一层难度。我找不到一个站得住脚的普适时间线，所以我不会给出具体数字。

Rust 适合作为第一门编程语言吗？

我的答案是否定的，但你应该知道，这个问题在资深从业者之间存在争议。在 r/rust 的“Struggling to learn Rust”帖子里， u/cassepipe 在碰壁之后绕道 C 和 C++ 再回来，直截了当地说 Rust“不是一门好的入门语言”，而 u/Voxelman 持相反观点：命令式语言是糟糕的起点，因为它们教给你的习惯之后还得再改掉。同样的争论在 Rust 自己的用户论坛上持续了整整四页。社区并没有一个可供报告的定论。

Rust 正在取代 C++ 吗？

没有。Rust 是被加入到 C 和 C++ 旁边，并被选用于特定的新组件，这是两回事。在 Linux 内核中，Rust 是与现有 C 代码库并存加入的，而不是整体取代它。在 Android 中，Google 公开的做法是用内存安全语言编写新代码，而不是转换现有的 C 和 C++ 代码。预计两者会长期共存。

Rust 比 Go 快吗？

这一点我没有做基准测试，所以不会断言哪个绝对更快。Rust 让你对内存分配有更细的控制，并且不需要垃圾回收器；Go 使用带垃圾回收的运行时，用一部分底层控制换取更简单的开发。哪个更快取决于工作负载、实现和瓶颈，所以请使用与你自己的应用相似的基准测试。