Bun 1.4.0 深度拆解：当 JavaScript 运行时遇上 AI 重写——从 Zig 到 Rust 的 11 天极限迁移

写在前面

2026 年 7 月 8 日，JavaScript 运行时 Bun 正式发布了 1.4.0 版本。这不是一个普通的小版本迭代——它是 Bun 核心代码从 Zig 完全迁移到 Rust 的首个正式版本，意味着这个集运行时、打包器、包管理器、测试运行器于一身的超级工具链，在诞生四年后迎来了自诞生以来最彻底的一次底层重构。

而这次重构的特殊之处，不仅在于语言层面的切换，更在于它的实现方式：整个迁移由 Claude Fable 5 驱动，11 天完成，耗费 16.5 万美元，迁移代码量超过 53 万行，产生了 6755 个 commit，新增代码超过 100 万行——GitHub 那个合并 PR 的页面甚至因为代码量太大而一度无法加载。

这是一个足够让整个开发者社区停下来思考的事件：AI 到底能不能接管大规模代码库的重写？六天 96 万行 Rust 代码，真的靠谱吗？这对整个开源生态意味着什么？

一、Bun 的 Zig 时代：一个理想主义者的孤独实验

1.1 从 esbuild 说起

要理解 Bun 为什么要重写，首先得理解它最初是怎么诞生的。

2021 年 4 月，一个叫 Jarred Sumner 的开发者在 GitHub 上扔出了一个项目——Bun。最早的 Bun，其实是对 esbuild（一个 Go 语言写的高速打包器）的 Zig 逐行移植。esbuild 是由 Go 实现的，而 Zig 的设计哲学与 Go 有几分相似：追求极致的底层控制、零成本的抽象、以及极其简洁的语法——Zig 的语言参考文档只有一页纸。

Jarred 选择 Zig 而不是 Go，核心原因是 Zig 能提供更直接的内存控制能力。对于一个要做 JavaScript 运行时 + 打包器 + 包管理器 + 测试框架的全栈工具链来说，这种底层控制能力至关重要。

在最初的那些日子里，Jarred 一个人在 Oakland 的一间小公寓里写代码。没有 VC 投资，没有团队，纯粹是个人项目。但就是这样一个项目，在一年内迅速积累了令人惊叹的功能集合：JavaScript/TypeScript/CSS 的转译与打包、npm 兼容的包管理器、一体化的测试运行器、Node.js API 兼容层、Web API 实现。每一项单独拎出来都够一个团队忙活半年，被一个人用 Zig 搞定了。

1.2 为什么是 Zig？

Zig 的设计哲学是没有隐藏的控制流，没有隐藏的内存分配，没有宏魔法。它追求的是代码的透明性——你写的每一行代码，编译器在做些什么，你应该能完全理解。

Bun 选择 Zig 的真正原因，是它提供了两个 Node.js 和 Deno 都无法提供的东西：

第一，极致的启动速度。Bun 的冷启动时间大约是 3 毫秒，而 Python 大约是 45 毫秒。这意味着对于 CLI 工具来说，丝滑响应和明显卡顿之间只差一个 Bun。

第二，JavaScript 引擎集成。Bun 内嵌了 JavaScriptCore（WebKit 的 JS 引擎），这让它能够以极低的开销执行 JavaScript 代码。对于 AI 编程工具来说，每次用户敲完一个命令就启动一个新进程的场景下，3ms vs 45ms 的差距会被放大无数倍。

这就是为什么 Anthropic 在开发 Claude Code 时，几乎是毫无悬念地选择了 Bun 作为其底层运行时。

1.3 繁荣背后的暗礁

从 2021 年到 2026 年初的四年多时间里，Bun 经历了爆发式增长：GitHub 星标从 0 涨到 9 万加，每周 npm 下载量数十万次。

然而，增长的背后是日益积累的技术债务。

内存泄漏是最严重的问题。2026 年 3 月，Claude Code 的 GitHub Issue #33453 记录了这样的现象：Claude Code 主进程在约 3 小时的短会话中，RSS 内存从 1.7GB 增长到 14GB 以上。罪魁祸首指向 Bun 运行时的 WebKit Malloc 分配器。另一份 Issue 记录得更夸张：运行 14 小时后，Claude Code 进程占用 23GB 虚拟内存，CPU 占用 143.8%，最终导致系统完全卡死。

4700 个 open issues 也是另一个令人不安的数字。作为对比，Node.js（驱动几乎整个互联网）大约有 1700 个 open issues，而 Bun——这个用户规模远小于 Node.js 的年轻项目——却有超过 3 倍于 Node.js 的积压问题。

Zig 本身的稳定性问题则是压垮骆驼的最后一根稻草。Zig 作为一个仍在快速迭代的语言，每个月都会进行重大更改。这让 Bun 的维护成本居高不下，而 Zig 编译器的崩溃、内存错误等问题层出不穷，这些底层问题往往没有简单的修复路径。

更讽刺的是，Bun 团队此前 fork 过 Zig 以优化编译速度，在 macOS 和 Linux 上通过引入 LLVM 并行代码生成让 debug 编译速度提升了四倍。但这些优化始终无法 upstream 回 Zig 官方——原因是 Zig 社区有极其严格的 no-AI policy，禁止 AI 生成 issue、PR 甚至评论。

二、Anthropic 收购：Bun 找到了金主，却没能解决根本问题

2.1 一笔改变格局的收购

2025 年 12 月，Anthropic 宣布收购 Bun。官方说法是加速 Claude Code 能力，但本质上，是要彻底打通 Claude Code 的底层技术栈：Bun 成为 Claude Code 的运行时、包管理器、打包器和测试工具的统一底座。

Anthropic Claude Code 负责人 Boris Cherney 曾解释过为什么选择 Bun：Claude Code 的每一次命令执行都要启动一个新的 Bun 进程，这种高频启动场景下，3ms vs 45ms 的差距会被放大到用户可以直接感知的程度。

但问题在于，Anthropic 的这次收购并没有自动解决 Bun 的稳定性问题。随着 Claude Code 用户量增加，Bun 的内存泄漏问题被放大到了前所未有的程度。

2.2 循环依赖的荒诞剧

这里出现了一个极其荒诞的逻辑闭环：Claude Code 依赖 Bun（Claude Code 以 Bun 可执行文件形式发布），Bun 的内存泄漏影响 Claude Code（长时间会话从 1.7GB 飙升到 14GB），Anthropic 收购 Bun（为了 Claude Code 更好用），Claude Code 被 Bun 的内存泄漏坑惨了（用户怨声载道），Anthropic 让 Claude 去重写 Bun（彻底解决底层问题），Bun 重写完成后继续支撑 Claude Code（完美自循环）。

这听起来像是一个黑色幽默，但它是真实发生的事情。

三、迁移策略：一份 576 行的手术指南

3.1 PORTING.md：机器翻译的施工图纸

2026 年 5 月初，Bun 的 GitHub 仓库里出现了一个名为 claude/phase-a-port 的新分支。分支里，数十万行 AI 生成的 Rust 代码与原始 Zig 实现并排存在。

同时出现的是一份极其详细的 PORTING.md 文档——长达 576 行的 Zig-to-Rust 迁移指南。这份文档本身就是一份杰作，它展示了如何用 AI agent 做大规模代码迁移。

文档将迁移拆成两个阶段：

Phase A：忠实翻译。Claude agent 逐文件将 Zig 代码翻译为 Rust，不要求 Rust 代码能够编译通过，允许留下 TODO 和编译错误，目标是保留原始逻辑的语义完整性。

Phase B：逐个突破。逐个 crate 解决编译错误，修复运行时行为，确保测试通过。

文档还有大量极其细致的规范：

• 文件命名：Zig 文件 src/foo.zig 对应 Rust 文件 src/foo.rs
• 禁止使用：tokio/rayon（性能开销）、hyper（HTTP框架）、futures（异步抽象层）、async fn in public API
• 必须遵守：unsafe 代码必须写明 SAFETY 注释，遇到不确定逻辑宁可留下 TODO，也不要让 AI 自行猜测，tagged pointer 保留原始设计，性能优先

这些规则体现了两个核心原则：先正确，再优化；性能不能妥协。

3.2 Phase A：Claude 的六天奇迹

从 5 月 3 日开始的 Phase A，整个进度以一种不像正常软件工程的速度推进。

5 月 7 日（第 5 天），Jarred 发推称：这次 Rust 迁移已经涉及约 4000 次 commit、96 万行代码，当时只剩下 3 个编译错误。

当时的 Rust 版本已经能够显示 help menu（虽然版本号还是错的），bun run 和 package.json scripts 已经可以执行，JSON parser、AST、logger、module resolver、文件系统遍历等一整串基础能力都已迁移完成。最重要的是：JavaScript runtime 已经可以运行 JavaScript。

Jarred 发了一条简洁有力的推文：JavaScript runtime runs JavaScript.

有网友惊呼：Claude 难道只用了三天就把 Zig 版 Bun 重写成 Rust 了吗？Jarred 的回复是：按代码量来看，这个说法准确。

5 月 9 日（第 7 天），进度跳到了另一个量级：Rust 重写版本在 Linux x64 glibc 环境下通过了 Bun 既有测试套件的 99.8%。

5 月 11 日（第 9 天），Jarred 发了那条引爆整个社区的推文：Bun v1.3.14 将于明日发布。如果我们合并 Rust 重写版本，这将是 Zig 的最后一个版本。

六天前，他还在 Hacker News 上说这是一堆根本还跑不起来的代码、最后被全部扔掉的概率非常高。六天后，同样的代码变成了 Zig 的最后一个版本。

四、争议风暴：六天重写 96 万行代码，靠谱吗？

4.1 unsafe 危机：73 vs 13,000

最大的质疑来自 t3.gg 创始人 Theo。5 月 12 日，他在 X 上发布了一组对比数据：

uv 包含 35 万行 Rust 代码，以及 73 个 unsafe 调用。Bun Rust 移植版已经有 68.1 万行 Rust 代码，并且有超过 13,000 个 unsafe 调用。

73 vs 13,000，差了接近 180 倍。这个数字迅速点燃了社区。有人直接称之为 vibecoded disaster——AI 随手生成的代码垃圾。

Jarred 几乎立刻做出了回应：今天已经下降了大约 2000。我预计它会稳定在 1 万左右，因为 Bun 的大部分内容都是用 C 和 C++ 编写的，文件系统、网络、JavaScript 引擎集成，这些都绕不开 unsafe。

这个解释在技术上有一定道理——Bun 内嵌了 JavaScriptCore 引擎，集成底层 C/C++ 代码的比例远高于 uv 这样的纯 Rust 项目。但网友的担忧并不只是 unsafe 的数量本身。

4.2 流程问题：AI 写、AI 审、AI 合

开发者社区的质疑逐渐从技术细节转向了一个更深层的工程流程问题。

网友 Aashish Ranjan Singh 在 X 上写道：uv 的 Rust 代码是由真正的开发人员编写的，每一行都经过了审查。Bun 的 Rust 由 Agents 编写，由 Agents 审核，并由 Agents 批准和合并。完全在意料之中的结果。

另一位用户更加犀利：uv 不是 vibecoded 的垃圾，开发它的人对 Rust 非常了解。但 Bun 就完全不同了，简直是一场风格灾难。用 Deno 吧。

还有人把矛头指向了收购方：Anthropic 正在强迫他们用 Rust 重写，这样他们糟糕的工程团队就可以通过怂恿 Claude 来搞砸它。

面对被迫重写的猜测，Jarred 亲自下场否认：没人逼我这么做。

但事实是，这个由 AI 驱动、缺乏充分人工审查的重写流程，确实在 Rust 社区引发了关于代码质量和工程诚信的广泛讨论。当代码生成速度远远超过人类审查速度时，我们该如何保证这些代码真的值得信任？

五、最终形态：Rust 版 Bun 的技术全景

5.1 架构设计：保持不变

从技术角度，Bun 的 Rust 重写保持了两个关键不变：

相同的架构设计。Rust 版本不是对 Bun 的重新设计，而是对原有架构的逐层迁移。这意味着原有的设计决策（如 event loop 模型、模块解析策略、打包流水线）都得以保留。

相同的数据结构。核心数据结构没有因为语言切换而重写。这确保了兼容性的基本盘。

5.2 Rust 带来了什么

尽管架构不变，Rust 语言的特性依然带来了几个层面的改善：

内存安全保证。Rust 的所有权系统和借用检查器在编译时就能捕获 dangling pointer、buffer overflow 等常见漏洞。对于一个每天处理数十亿次请求的 JavaScript 运行时来说，这种保障意味着某些类型的 bug 从根本上消失了。

二进制体积优化。重写后，二进制文件体积缩小了 3-8 MB。对于一个需要被数十万用户频繁下载的工具链来说，这是不小的改善。

性能提升。在各平台上，性能测试均达到或超越了 Zig 版本的原有水平。部分场景提速约 5%。

修复了长期积累的 bug。重写过程中，Rust 编译器成为了一个极其严格的代码审计员——它不允许模糊的内存操作、不允许悬空指针、不允许未定义行为。这些编译期的强制检查，实际上等同于对整个代码库进行了一次系统性的安全审计。

5.3 为什么不用 tokio/async Rust

值得注意的是，Bun 的 Rust 版本没有使用 tokio（最流行的 Rust async 运行时），也没有使用 async Rust。

这是因为 Bun 的整个设计是围绕同步执行模型构建的。Bun 的 event loop 是单线程的，通过非阻塞 I/O 实现并发，但核心执行逻辑是同步的。引入 tokio 或 async/await 语法会从根本上改变这种设计，并带来不必要的复杂性。

这体现了 Jarred 的一个核心工程哲学：选择工具时，架构契合度优先于流行度。

六、AI 重写软件：一场正在发生的范式转移

6.1 不止是 Bun

如果 Bun 的六天重写只是一个孤例，或许我们可以把它当成有钱任性的技术花边新闻。但事实是，类似的 AI 驱动极限重写正在多个领域同时发生：

Cloudflare 曾在一周内借助 AI 重新实现了 Next.js API 的大部分能力。Ladybird 浏览器 在两周内将自己的 JavaScript 引擎从 C++ 迁移到了 Rust。

而在这之前，Jarred 本人曾在 5 月 3 日发过一条推文，预言了一种新的软件工程流水线：这种 pipeline，任何 VC 支持的 OSS 或者有大量 GitHub issues 的公司都能搭建。更普遍地说，它可以用于自动修复用户报告的 bug。

他在更早的时候就预言过更激进的场景：我预计开源软件会走向完全相反的方向——未来甚至可能变成禁止人类贡献代码。人类依然会负责讨论问题、决定优先级，但真正写代码、提交 PR、回复和处理反馈、完成实现的工作，最终都会由 LLM 来完成。

Bun 的这次重写，正是这句话的第一次大规模公开演练。

6.2 AI 重写的真实能力边界

通过 Bun 的案例，我们可以清晰地看到 AI 重写的能力边界：

AI 能做到的事情：大规摸语法翻译（Zig 到 Rust）；保持逻辑的语义一致性；在有完整测试套件的情况下快速验证；在有清晰规范的情况下生成符合预期的代码。

AI 做不到或做不好的事情：自主判断架构决策的优劣；发现原始代码中的逻辑 bug（它会忠实复制所有 bug）；在没有明确规范时做出正确的工程权衡；独立处理 unsafe 代码的内存安全问题；替代人类的批判性思维和工程直觉。

这就是为什么 Bun 的 Phase A/Phase B 策略如此重要：Phase A 让 AI 做它擅长的事情（忠实的机械翻译），Phase B 让人类和 AI 协作处理它不擅长的事情（编译错误、性能调优、安全审计）。

6.3 一个值得深思的数字

最后，让我们回到那个争议的核心：13,000 个 unsafe。

如果仔细看这个数字，Bun 的 Rust 版本有 68 万行 Rust 代码，而 uv 有 35 万行 Rust 代码。uv 的 unsafe 数量是 73，Bun 是 13,000。

除了 Bun 需要与大量 C/C++ 代码交互（JavaScriptCore 引擎集成、libuv 级别的 I/O 操作等）之外，还有一个因素：Bun 的 Phase A 是忠实翻译，Claude agent 倾向于在遇到 Zig 的 unsafe 操作时，直接翻译为 Rust 的 unsafe——因为这样语义最接近，不需要 agent 做额外的架构决策。

换句话说，13,000 个 unsafe 中的相当一部分，是 AI 在忠实复制而非智能重构。如果由经验丰富的 Rust 工程师来迁移，他们可能会选择用 safe Rust 抽象封装 unsafe 操作，而不是直接暴露每一个 unsafe 调用。

这提醒我们：AI 擅长翻译，但真正的工程价值在于选择翻译的策略。

七、站在十字路口：Bun 的下一步与 JS 运行时的未来

7.1 Rust 版本之后：优化仍在进行

Jarred 在合并 Rust 版本后明确表示：优化工作仍在进行中，最终版本发布前还会有一些清理工作。目前 Rust 版 Bun 通过 bun upgrade --canary 开放测试，让早期用户帮助发现问题。

从工程角度，这是一个成熟开源项目应有的节奏——不为了抢首发而牺牲质量，用 canary 频道让社区参与测试，同时保持 stable 频道的稳定性。

7.2 JS 工具链的 Rust 大一统

如果把 Bun 放进更大的趋势来看，会发现一个清晰的脉络：

打包工具：esbuild（Go）→ Rolldown/Oxc（Rust）。前端框架：Webpack（JS）→ Vite+Rust 工具。运行时：Node.js（C++）→ Deno（Rust）→ Bun（Rust）。包管理器：npm（JS）→ pnpm（Rust）→ Bun（Rust）。

Rust 正在成为前端和工具链领域的新 C++——它提供了 C++ 的性能和控制能力，同时提供了现代语言的内存安全保证。对于需要极致性能的工具链来说，这几乎是最优选。

7.3 AI 与人类工程师的新分工

Bun 的案例给整个行业提出了一个绕不开的问题：当 AI 能以人类无法企及的速度完成代码迁移时，人类工程师的价值在哪里？

答案可能不在写代码本身，而在于：定义迁移目标（告诉 AI 我们要做什么，而不是怎么写）；建立迁移规范（编写 PORTING.md 这样的详细迁移指南）；验收与审计（检查 AI 生成的结果是否真正符合预期）；处理边界情况（AI 无法处理的异常场景、架构权衡）。

Bun 的 Phase A/Phase B 策略，某种程度上就是这个新分工的原型：AI 负责高吞吐的代码生成，人类负责质量把关和关键决策。

八、总结：一次改变认知的激进实验

Bun 的这次从 Zig 到 Rust 的迁移，是 2026 年技术圈最值得关注的工程实验之一。

它用 11 天、53 万行代码、16.5 万美元，向整个行业展示了 AI 在大规模代码迁移中的真实能力边界——极快的速度，极高的吞吐量，但需要人类的框架和规范作为约束。

它也揭示了 AI 时代软件工程的一个核心矛盾：当代码生成速度远远超过人类审查速度时，我们如何保证代码质量？Bun 的答案是分阶段流水线加完整测试套件验证，但这个答案是否可复制，还需要更多项目来验证。

对于 JavaScript 工具链生态来说，Bun 1.4.0 的发布是一个里程碑事件。它证明了 Rust 不仅可以替代 Zig 实现同等的功能和性能，还能带来内存安全、二进制优化和代码可维护性方面的改善。

而对于整个软件工程领域来说，Bun 的实验提出了一个更大的问题：未来，人类写的代码和 AI 写的代码之间的边界在哪里？

这个问题没有标准答案。但至少在今天，我们可以说：Bun 已经给出了它的答案——让 AI 处理重复，让人类专注决策。

参考资料：Bun 官方博客 - The Road to Rust (2026.07.08)；Jarred Sumner X 动态整理；GitHub PR #30412 - Rust migration merge；PORTING.md - claude/phase-a-port 分支；CSDN 技术社区相关报道；OSCHINA 开源中国相关报道；IT之家相关报道。