2026 年 5 月：Bun 项目大规模代码迁移

2026 年 5 月，Bun 项目完成了一次在软件开发史上近乎罕见的大规模代码迁移。这次迁移从 5 月 3 日启动，到 5 月 14 日正式合并入主分支，只用了 11 天。写代码只用了 6 天，并且整个过程公开。不过，Jarred Sumner 写博客总结却花了快一个月，比写代码的时间长多了。

迁移详情：超百万行代码变更，花费 16.5 万美元

这个 JavaScript 运行时原本拥有 535,496 行 Zig 代码（不包括注释），同时，约 20% 的代码由 C++ 编写，并嵌入了多个 C/C++ 库。此次借助 AI 重写为 Rust，整个过程涉及超过 100 万行代码变更、6778 次提交，并在 Claude Code 中运行了大约 50 个动态工作流（dynamic workflows）。根据 Sumner 披露的数据，这次重写在 API 层面消耗了 59 亿个未缓存输入 token、6.9 亿个输出 token，以及 720 亿个缓存输入 token 读取，按 API 定价计算约花费 16.5 万美元。Sumner 说，这是目前技术所能达到的前沿水平。他估计，如果让 3 名完全熟悉 Bun 代码库的工程师手工完成这次迁移，大约需要一年时间，而且在这一年里，团队几乎无法继续推进新功能开发、bug 修复和安全修复。这次重写之后，Bun v1.3.14 成为最后一个 Zig 版本，Bun v1.4.0 将成为第一个 Rust 版本。

成果：从 6.7GB 内存泄漏到 609MB 稳定

Bun 最初是一个 Zig 项目，覆盖面非常广：它既是 JavaScript 和 TypeScript 转译器，也是打包器、包管理器、测试运行器、模块解析器、HTTP 和 WebSocket 客户端，还实现了 Node.js API 层。正是这样的产品宽度，让 Bun 的 CLI 月下载量超过 2200 万次，并获得了 Vercel、Railway、DigitalOcean、Claude Code 和 OpenCode 等项目或公司的支持。但同样是这种宽度，也给 Bun 带来了一些挑战。特别是在 Bun v1.3.14 中，有一个让大家头疼已久的问题：连续执行 Bun.build() 调用时，内存会不断累积，永不释放。每次构建大约泄漏 3MB，看起来不多，但如果运行的是一个开发服务器，每次请求都触发一次构建，那么内存就会被一点点吞噬，直到进程崩溃。在实际测试里，执行 500 次构建后内存占用 1.9GB，1000 次后 3.5GB，1500 次后 5.1GB，2000 次后飙升到 6.7GB。这只是诸多内存问题的冰山一角。在 v1.3.14 的 bug 修复清单中，Sumner 列出了一长串问题。这些 bug 的共性非常明显——它们几乎都指向同一个根源：将 GC 与手动内存管理在同一个软件里混合使用。更令人焦虑的是，团队并非没有努力，但崩溃报告仍然源源不断。而 Rust 版本交出的答卷是：同样执行 2000 次 Bun.build()，内存稳定在 609MB。除了内存泄漏问题得到根本性解决，Rust 重写还带来了其他几个维度的改善。在稳定性方面，v1.4.0 修复了 v1.3.14 中可复现的 128 个 bug，从内存泄漏到崩溃到颜色显示错误的帮助文本都得到了解决。从体积上，结合 Rust 重写、ICU 更改和相同的代码折叠，Bun 在 Linux 和 Windows 上的二进制文件大小减少了约 20% 。在性能方面，普遍提升了 2% 到 5%。Bun.serve 从 16.96 万 req/s 提升到 17.77 万 req/s，node:http 从 10.38 万提升到 10.85 万。实际应用场景中，next build 从 13.62 秒降至 13.03 秒，tsc 批量编译从 0.94 秒降至 0.89 秒。而 Claude Code 在基于 Rust Bun 发布后，Linux 上的启动时间从 517ms 降至 464ms，快了约 10%。

方法：64 个 Claude，11 天，50 个工作流

Sumner 是怎么做到的，这可能是最值得关注的部分——因为他用的方法，和传统的“让 AI 写代码”不同。Sumner 把整个过程拆成了大约 50 个动态工作流，每个工作流都是一个循环。他在博客里用伪代码描述了这个模式。这种模式贯穿了整个重写过程。每个工作流负责一个特定目标。峰值时期，Sumner 同时运行了 4 个工作流，每个工作流里 16 个 Claude，总共 64 个 Claude 同时在 4 个工作树中并行工作，各自提交和推送文件。在最高峰时，Claude 每分钟写了约 1300 行代码。这种“实现者 / 审查者”的分离设计是关键。代码写完只是第一步。接下来是让 bun --version 跑起来，然后是 bun test。两天后，Linux 平台的失败测试从 972 个降到了 23 个。一天半之后，Linux 全绿了。五天后，全部六个平台——Linux x64、Linux arm64、macOS x64、macOS arm64、Windows x64、Windows arm64——全部通过。5 月 14 日，PR #30412 正式合并，测试套件全部通过，没有跳过或删除任何测试。

隐忧：13,000 个 unsafe 和无法逐行审查的代码

不过，Sumner 也承认，这项工作还没有真正结束。截至目前，Bun 的 Rust 代码中大约有 4% 位于 unsafe block 内，约 13,000 个 unsafe 关键字，分布在约 27,000 行代码中，而 Rust 总代码量约为 780,000 行。他预计后续重构会让这个比例降下来，但 Bun 的 unsafe 数量与 uv 的差距很难用“需要调用 C 库”来解释。并且随后还在安全 Rust 代码中也暴露了未定义行为。Sumner 自己也承认，这次重写引入了 19 个已知的回归问题，并表示大多数回归问题都源于语法相同但语义不同的代码。虽然已经问题都修了，但这并不表示百万行 AI 代码就没有其他问题。还有一个不能忽略的事情是代码审查。100 万行的变更实际上没法由人类逐行看。这次 PR 的审查者主要是 claude[bot] 和 coderabbitai[bot]。Sumner 自己也承认，他的审查方式是“检查对抗性审查 agent 是否正确捕获了差异，确保转换指南被遵守，同时自己也手动读了不少代码”，但“不少”是多少，他没说。还有一个绕不开的问题：Bun 在 2025 年 12 月被 Anthropic 收购了，真正能有效维护这套代码库的工具，基本只有 Claude 自己。社区里有人说，这已经算不上传统意义上的开源项目了。

16.5 万美元换一年工作量，值吗？

Sumner 在博客中还披露，这次重写的 API 成本约为 16.5 万美元，等于 3 名工程师一年的工作量。这个数字在 Hacker News 上引发了激烈的讨论。有人认为，这笔账其实很划算。但也有人指出，把成本简化成 API 定价，是在刻意淡化真实投入。而且目前看来，虽然 16.5 万美元换一年工作量，账面上看挺划算，但真正的成本不在这张账单上。这个代码库有 6778 次提交，没有一个人从头到尾完整读过，虽然眼下一切正常，可未来维护成本怎么算，其实挺难。那么，你认为 16.5 万美元换一年工作量，到底值吗？