当“安全性”遭遇“交付速度”：2026 年，我为什么告别了 Rust

本文永久链接 – https://tonybai.com/2026/02/21/safety-vs-delivery-speed-why-farewell-rust-in-2026

大家好，我是Tony Bai。

在软件工程的铁三角中，Rust 占据了“安全性”与“性能”的绝对高地。凭借借用检查器（Borrow Checker）和极其严格的类型系统，它向开发者承诺了一个没有内存错误、没有空指针崩溃的完美世界。

然而，在商业软件开发的战场上，还有一个至关重要的维度往往被技术纯粹主义者忽视，那就是——交付速度（Delivery Speed）。

近日，资深工程师 Dmitry Kudryavtsev 发表了长文《Farewell, Rust》，详述了他为何忍痛将一个运行了多年、已盈利的 Rust 项目全盘重写为 Node.js 的心路历程。这篇文章也引发了一场关于“为了极致的安全性，我们是否值得牺牲过多的交付速度？”的深刻辩论。

缘起：一个 C/C++ 老兵的“安全梦”

Dmitry 绝非那些被即时编译（JIT）宠坏的脚本小子。相反，他的技术底色是硬核的 C/C++。

早在高中时代，他就沉迷于指针的魔力，痴迷于手动管理内存的掌控感。他写过 3D 渲染器、IRC 机器人，甚至操作系统内核。然而，由于第一份工作是 PHP Web 开发，他被迫进入了动态语言的世界。虽然 PHP、Python 和 Ruby 带来了 Web 开发的极速体验，但在内心深处，他始终怀念 C 语言那种“压榨硬件每一滴性能”的快感，同时也痛恨 C 语言中防不胜防的内存安全漏洞。

直到 Rust 横空出世。

对于像 Dmitry 这样的工程师来说，Rust 简直就是“鱼与熊掌兼得”的梦想：

低级控制力：像 C 一样精确控制内存布局。
安全性：编译器在编译阶段就能消除一整类内存错误。
现代体验：拥有像 Cargo 这样优秀的包管理工具。

于是，他做了一个所有热血工程师都会做的决定：为了追求极致的质量与安全，用 Rust 从零构建一个商业 Web 应用。

起初，一切都很完美。他在 2023 年底成功上线了项目，甚至因此受邀在两个技术大会上发表演讲。但随着时间的推移，业务逻辑日益复杂，“安全性”的红利开始被“交付速度”的损耗所抵消。到了 2026 年初，为了项目的生存，他不得不做出了那个艰难的决定：告别 Rust。

深度复盘：Rust 在 Web 交付中的“五大减速带”

Dmitry 的文章之所以珍贵，是因为他用亲身经历证明了：在 Web 开发的特定场景下，Rust 引以为傲的“安全性”机制，如何一步步变成了拖慢“交付速度”的罪魁祸首。

1. 模板与视图：类型安全 vs. 迭代速度

在后端逻辑中，Rust 的类型系统坚不可摧。但当数据流向前端（HTML/Email 模板）时，这种为了安全而设计的严格性，变成了修改 UI 时的噩梦。

安全性的代价：为了保证编译时的类型安全，Rust 社区诞生了 Maud 或 Askama 这样的编译时模板库。它们通过宏（Macro）在编译期检查 HTML 模板中的每一个变量引用。这听起来很棒，意味着你永远不会渲染出错误的变量。
速度的牺牲：但这带来的副作用是，每次修改 HTML 哪怕一个标点符号，都会触发漫长的重新编译。在 Web 前端开发这种需要“所见即所得”的高频迭代场景下，这种等待是毁灭性的。
对比 Node.js：TypeScript 配合 JSX/TSX 提供了全链路的类型安全，同时保持了极快的热重载（Hot Reload）速度。重构一个字段，VS Code 会立即标红所有受影响的视图组件，修改后毫秒级生效。这种“安全且快”的体验，是 Rust 目前无法提供的。

2. 国际化（i18n）：生态缺失带来的效率黑洞

对于商业应用，支持多语言是刚需。

虽然 Mozilla 开发了 Project Fluent，但 Rust 生态中缺乏成熟的、开箱即用的 i18n 解决方案。你往往需要为了“正确性”而去处理繁琐的加载逻辑和类型绑定，编写大量的胶水代码。而Node.js生态中的i18next 等库不仅极其成熟，还能配合 TypeScript 提供键值级别的类型安全。Node.js 原生内置了完整的 ICU 标准（Intl API），处理货币、日期、复数格式化信手拈来。在这一点上，Rust 开发者需要花费数倍的时间来实现同样的功能，严重拖慢了产品推向全球市场的速度。

3. “动态”业务 vs. “静态”约束

Web 业务充满了动态性：用户提交的 JSON 结构可能是不确定的，筛选条件的组合可能是无穷的。Rust 试图用静态类型系统去约束这些动态行为，结果就是开发效率的暴跌。

序列化之痛：serde 是 Rust 的瑰宝，但在处理复杂的、充满 Option 的业务数据时，为了安全地取出一个嵌套字段，你不得不编写大量的 match 或 unwrap 处理代码。为了优雅地处理错误，Dmitry 定义了十几个自定义错误枚举。虽然代码很健壮，但写起来太慢了。
SQL 的僵局：sqlx 提供了极其强大的编译时 SQL 检查，这在静态查询时非常棒。但是，一旦你需要根据用户输入动态构建查询（例如：用户选了 A 筛选条件就加个 WHERE 子句），Rust 的强类型系统就变成了噩梦。你无法像在 Node.js 中使用 Kysely 或 Prisma 那样，流畅地拼接查询片段。为了“安全”地构建 SQL，你付出了巨大的代码复杂度成本。

4. 编译时间：CI/CD 的隐形杀手

这是最让 Dmitry 崩溃的一点，也是“交付速度”最直观的体现。

Rust 的等待：随着依赖增多（尤其是使用了大量宏的 Web 框架），编译时间呈指数级增长。Dmitry 的 CI 流程需要 12-14 分钟才能完成部署。“每次我在 Sentry 上看到一个简单的 Bug，想到修复它需要等待 15 分钟的构建流程，我就失去了修复的动力。”
Node.js 的极速：迁移到Node.js后，完整的 CI 流程（含 Lint 和测试）仅需 5 分钟。部署速度提升了 3 倍。这意味着“发现 Bug -> 修复 -> 上线”的反馈闭环被大大缩短了。在商业竞争中，修复速度往往比绝对的“无 Bug”更重要。

5. 生态成熟度：造轮子的时间成本

Rust 的 Web 生态虽然在成长，但面对长尾需求时仍显稚嫩。

场景：你需要集成一个冷门的第三方支付网关，或者处理一个特定的 Webhook 签名验证。
Rust 的困境：官方 SDK？没有。社区库？两年前就不更新了。为了安全，你不得不对着 API 文档，自己手写 HTTP 请求、自己实现加密验签逻辑。这占用了大量本该用于开发业务核心功能的时间。
Node.js 的便利：npm install 通常能解决一切。几乎所有 SaaS 服务商都会提供第一方的 Node.js SDK。“拿来主义”是提升交付速度的最佳捷径。

总结与反思：我们到底为了什么而编程？

Dmitry 的文章并没有否定 Rust 的价值。相反，他依然热爱 Rust，依然怀念那些与编译器“斗智斗勇”并最终获得完美代码的日子。

他的结论非常客观，为所有正在做技术选型的团队提供了一把衡量“安全”与“速度”的标尺：

资源占用 vs. 开发效率的账本
Rust 版本的应用内存占用仅 60-80MB，而 Node.js 版本约为 117MB。
Rust 确实更省资源。但对于业务应用来说，这 50MB 的内存差异，在云服务器几美元一个月的成本面前不值一提。然而，为了节省这 50MB 内存，开发者付出了几倍的开发时间、调试精力以及心智负担。这笔账，在商业逻辑上是划不来的。
技术选型的“黄金法则”
- 何时拥抱“安全性”（选 Rust）：如果你在构建数据库内核、搜索引擎、高频交易系统、嵌入式设备固件，或者像 Lambda 这样对冷启动时间极度敏感的 Serverless 函数。在这些场景下，性能和稳定性是核心竞争力，为了安全牺牲开发速度是值得的。
- 何时拥抱“交付速度”（选 Node.js/Go/Python）：如果你在构建 CRUD 后端、SaaS 业务逻辑、内部管理工具，或者处于需要快速试错、频繁变更需求的初创阶段。在这些场景下，迭代速度（Velocity）才是核心竞争力。
给 Go 开发者的启示
有趣的是，Dmitry 在注脚中提到了 Go：“Yes, there is Go. But I never really had the chance to like Go.”
这其实是一个非常有意思的信号。在 Rust 的“极致安全”和 Node.js 的“极致速度”之间，Go 恰恰占据了那个“黄金平衡点”：
- 它有静态编译和类型系统，比 Node.js 更安全、性能更好。
- 它有极快的编译速度和简单的语法，比 Rust 的心智负担低得多。
- 它有极其成熟的中间件和微服务生态。
对于那些厌倦了 Node.js 运行时错误，又被 Rust 借用检查器拖慢脚步的 Web 开发者来说，Go 依然是当下最务实的选择。