编程 Bun 从 Zig 重写为 Rust：AI 11天完成百万行代码迁移，开源社区震动

2026-07-14 12:44:45 +0800 CST views 7

Bun 从 Zig 重写为 Rust：AI 11天完成百万行代码迁移，开源社区震动

前言：当一个 JavaScript 运行时选择"叛逃"

2026年7月8日，Bun 创始人 Jarred Sumner 在 GitHub 和社交媒体上宣布了一条重磅消息：经过11天的高强度工作，Bun 全部1448个 Zig 文件已被完整迁移为 Rust 代码。64个 Claude 实例并行运行，编写了超过100万行 Rust 代码，总成本约16.5万美元。如果这个工作量交给人工团队来做，预估需要整整一年时间。

这条消息迅速引爆了技术社区。有人在 Hacker News 上称这是"AI 编程的里程碑时刻"，也有人质疑这种机械翻译的质量，更有人——Zig 语言的创始人 Andrew Kelley——直接站出来反驳，说这场"叛逃"不是技术问题，而是"价值观体系的背离"。

本文将深入剖析这场轰动一时的技术迁移：从 Zig 到 Rust 的真实原因是什么？AI 在这次迁移中究竟扮演了什么角色？迁移后的代码质量如何保证？以及这次事件对整个开源生态和 AI 编程的未来意味着什么？

一、Bun 是什么？为什么要从 Zig 开始说起

要理解这场迁移的来龙去脉，先要搞清楚 Bun 是什么，以及它为什么最初选择了 Zig。

Bun 是一个全栈 JavaScript 运行时，由 Jarred Sumner 从零开始构建。它的目标是成为一个比 Node.js 更快、更现代的替代方案——不仅是运行时，还集成了打包器、转译器、包管理器和测试框架。Bun 使用 JavaScript/TypeScript 原生编写，应用层完全不需要修改，但底层性能远超 Node.js。

Bun 最初选择 Zig，有几个关键原因：

第一，Zig 的控制力。 Zig 被设计为 C 的替代品，强调显式内存管理和零成本抽象。与 Rust 不同，Zig 没有垃圾回收，也不强制内存安全，而是把控制权完全交给开发者。这对于追求极致性能的 JavaScript 运行时来说是理想选择——你可以像写 C 一样精确控制每一个内存字节。

第二，Zig 的简单性。 Zig 的语法相对简洁，没有 Rust 那样复杂的生命周期和所有权系统。对于一个个人项目来说，Zig 的学习曲线比 Rust 更平缓。

第三，Bun 诞生时的背景。 Bun 最初是 Sumner 的个人项目，于2021年启动。那时候 Rust 在系统编程领域已经有一定影响力，但 Zig 还是一个更新、更"酷"的选择。一个个人项目选择 Zig，是很自然的事。

然而，四年过去了，情况发生了根本性变化。

二、从 Zig 到 Rust：触发点是什么？

Sumner 在官方博客中详细解释了这次迁移的决定。核心原因很直接：Zig 的稳定性问题已经无法继续忍受了。

Zig 语言仍然处于快速迭代期，标准库和语言本身都在不断变化。对于一个数万人依赖的生产级项目来说，这意味着：

内存错误层出不穷。 Bun 的 GitHub issue 中，有大量关于 Zig 版本导致内存泄漏和崩溃的报告。Zig 的内存管理虽然灵活，但缺乏编译器的强制保障——很多错误只有在运行时才会暴露，而这些错误在复杂的 JavaScript 运行时环境中极难调试和修复。

一次严重的上游事故。 2026年，Zig 编译器的一个 upstream 变更导致 Bun 的某个版本直接泄露了 Claude Code 的部分源代码。虽然问题的根源在 Zig 编译器，但 Bun 团队为此承受了巨大压力，这让 Sumner 意识到 Zig 的稳定性问题已经到了不可接受的地步。

被 Anthropic 收购后的战略调整。 2026年初，Bun 被 Anthropic 收购，成为 Claude Code 等内部 AI 开发工具的核心基础设施。这个背景意味着 Bun 的用户群体从"个人开发者和极客"扩展到了"企业级 AI 应用"，对稳定性的要求陡然提高。

Rust 提供了 Zig 所没有的关键保证：编译时内存安全。大量原本在运行时才会暴露的内存错误，在 Rust 编译器面前无所遁形。Sumner 估计，迁移到 Rust 后，Bun 可以消除大部分最难调试的内存相关 bug。

三、AI 迁移流水线：技术细节全解

这次迁移最引人注目的不是结果，而是过程本身。Sumner 透露，迁移过程完全由 Claude 驱动，使用了某种形式的自动化流水线。以下是根据公开信息重构的迁移方案：

3.1 迁移策略：机械翻译而非人工重写

这次迁移的本质是一次机械式语言翻译，而不是架构重写。Sumner 明确表示，新版本保持了原有的架构设计、相同的数据结构和相同的性能特征。Rust 版本不是"Bun 2.0"，而是一个"翻译版本"。

这意味着团队在迁移过程中遵循了几个重要原则：

不改变任何业务逻辑
不重新设计任何核心算法
保持相同的 API 表面和对外行为
所有第三方依赖的使用方式保持不变

这是一个聪明的选择。对于一个拥有数万名用户的开源项目来说，"重写"的最大风险不是迁移本身，而是新版本可能带来的行为差异。通过保持架构不变，团队可以将验证工作集中在"行为一致性"上，而不是"功能正确性"上。

3.2 并行化流水线：64 个 Claude 实例如何协作

Sumner 使用了64个 Claude 实例并行运行，每个实例负责处理一部分 Zig 文件。这种并行化策略的关键挑战是：如何管理依赖关系？

在典型的编程语言迁移中，一个文件通常会引用其他文件中的函数、结构体和模块。如果多个实例并行处理相互依赖的文件，就可能出现逻辑冲突或不一致的翻译。

一个合理的推测是，团队首先对1448个 Zig 文件进行了依赖图分析，然后将文件按层次分组——先翻译没有依赖或依赖最少的文件，再翻译依赖这些文件的文件，以此类推。每个 Claude 实例拿到的是一组独立的翻译任务，可以并行执行而不产生冲突。

3.3 Rust 的选择：不使用 async Rust

一个值得注意的技术决策是：迁移后的 Bun 仍然不使用 async Rust。

这是因为 JavaScript 运行时本身是高度异步化的——事件循环、Promise、async/await 构成了 JavaScript 的核心并发模型。Bun 的异步实现直接映射到操作系统的异步 I/O 机制（epoll、kqueue、IOCP），使用 Rust 的同步系统调用配合轻量级线程（类似 Go 的 goroutine）来实现高效并发。

引入 async Rust 会为这个架构增加不必要的复杂性。Rust 的 async/await 生态系统虽然成熟，但与 Zig 的同步风格在语义上有显著差异。保持同步 Rust 使得迁移工作更加"机械"——几乎是一行对一行的翻译，而不是语义上的重新设计。

3.4 移植后的关键数据结构

根据 Sumner 的描述，以下是移植中保持不变的核心数据结构：

JavaScriptCore (JSC) 集成层： Bun 使用 JavaScriptCore（WebKit 的 JavaScript 引擎）作为核心解释器。这部分代码的移植需要精确对应 JSC 的 C++ FFI 接口，是迁移中工作量最大、风险最高的区域之一。

HTTP 服务器实现： Bun 内置了一个高性能 HTTP 服务器，其核心实现在移植中保持了零拷贝和最小化内存分配的设计哲学。Rust 版本需要完全对等地实现这些特性。

文件系统 API 和路径处理： 跨平台路径处理（POSIX vs Windows）逻辑在 Zig 版本中经过了充分测试，Rust 版本需要完全复现这些边界条件和特殊处理。

四、测试体系：如何保证100%通过率

100万行代码的迁移，最核心的验证手段不是代码审查，而是现有的测试套件。Sumner 透露，新版本通过了 Bun 完整的测试套件，覆盖所有平台。

Bun 的测试套件包括：

JavaScript 引擎测试： 与 V8 和 JavaScriptCore 引擎的兼容性测试，确保 JavaScript 语义的正确执行。这些测试涵盖了 ES2024 及更早版本的所有特性。

// Bun 引擎测试示例：Proxy 代理对象行为
const target = { count: 0 };
const handler = {
  get(target, prop) {
    if (prop === 'count') return ++target.count;
    return target[prop];
  }
};
const proxy = new Proxy(target, handler);
console.log(proxy.count); // 1
console.log(proxy.count); // 2
console.log(proxy.count); // 3

Node.js API 兼容性测试： Bun 声称与 Node.js API 高度兼容，测试套件包含数千个针对 fs、path、http、crypto 等核心模块的行为验证。

// Node.js API 兼容性测试示例：fs 模块
import { readFile, writeFile } from 'node:fs/promises';

const testFile = '/tmp/bun-migration-test.txt';
await writeFile(testFile, 'migration-test-content', 'utf8');
const content = await readFile(testFile, 'utf8');
console.log(content === 'migration-test-content'); // true

性能基准测试： 专门的性能测试套件，验证新版本在 HTTP 服务器、文件 I/O、加密操作等核心场景下的性能不劣于 Zig 版本。

测试执行策略上，团队采用了分平台逐步推进的方式：首先在 Linux x64 glibc 环境下运行完整测试套件（99.8% 通过率），然后逐步扩展到 macOS（x64 和 ARM64）和 Windows。这个策略确保了每次发现问题都能快速定位到具体的文件和变更。

五、争议：Andrew Kelley 的反驳与价值观冲突

迁移公告发布后，Zig 创始人 Andrew Kelley 在社交媒体上发表了一份措辞激烈的声明，直接反驳了 Sumner 的说法。他的核心观点是：这次迁移不是因为 Zig 不够好，而是 Bun 团队的使用方式有问题。

Kelley 的反驳集中在以下几个方面：

第一，Zig 的内存安全问题不是 Zig 的问题。 他指出，Zig 的内存模型要求开发者显式管理内存，这对于愿意投入精力的开发者来说是优势而非劣势。他暗示 Bun 的 Zig 代码中存在大量"不规范"的内存使用模式，这些模式在任何一个强类型语言中都可能引发问题。

第二，Rust 并非银弹。 Kelley 指出，Rust 同样存在内存问题——数据竞争、内存泄漏（通过 Rc、Arc 和 UnsafeCell）、死锁等。Rust 的编译器只能保证特定类型的内存安全，不能保证所有内存问题。"选择 Rust 解决 Zig 的问题，就像用铁锤解决螺丝刀的问题——能用，但不一定是最合适的工具。"

第三，价值观的背离。 他在 Hacker News 的讨论中写道："这不是一个技术决策，而是一个价值观决策。Bun 选择了一条更保守、更追求'不出错'的道路，而 Zig 代表的是另一种理念——给开发者最大的控制权，即使这意味着更大的责任。"

这场争议引发了社区的广泛讨论。支持 Sumner 的人认为，Bun 作为一个有企业用户依赖的生产级项目，稳定性和安全性高于一切，选择 Rust 是务实之举。而支持 Kelley 的人则认为，放弃 Zig 意味着放弃了语言层面的创新和探索，是对 Zig 社区的一种打击。

六、性能与稳定性：迁移后的实际表现

根据 Bun 团队发布的基准测试数据，Rust 版本在多个关键指标上实现了改进：

内存使用量下降。 Zig 版本的某些场景下存在内存泄漏问题，这些问题在 Rust 版本中得到了根本解决。对于长时间运行的 HTTP 服务器场景，内存占用曲线更加平稳。

二进制文件体积缩小3-8 MB。 Rust 的链接策略与 Zig 不同，优化后的 Rust 二进制文件整体更小。对于分发和部署来说，这是一个实际的好处。

启动速度维持不变。 JavaScript 运行时的启动速度主要由引擎初始化和模块加载决定，语言层面的切换对启动性能影响很小。

运行时性能持平或略有提升。 大部分基准测试显示 Rust 版本与 Zig 版本性能相当，部分测试有约5%的提升。这是因为两者都生成了优化的机器码，关键热路径的性能瓶颈在于算法和数据结构，而不是编程语言本身。

七、AI 编程的新边界：这次迁移教会我们什么？

这次迁移之所以引发广泛关注，是因为它代表了一种全新的软件开发范式：用 AI 驱动大规模代码迁移。

传统上，代码迁移（从一种语言迁移到另一种语言）被认为是软件工程中最高风险的工作之一。Mozilla 将 Netscape 的代码从 C++ 迁移到 JavaScript（结果惨烈）、Twitter 从 Ruby 迁移到 Scala（代价巨大）——这些历史案例都证明了重写的高风险性。

但 Bun 的案例展示了一种不同的可能性：如果迁移的目标是"机械翻译"而非"架构重设计"，且有完善的测试体系作为保障，那么 AI 驱动的迁移是可行的。

关键条件有三个：

第一，目标语言和源语言的表达能力需要大致对等。 Rust 和 Zig 都是系统编程语言，都支持底层内存操作、高性能计算和直接系统调用。两者的语义差异主要在内存安全模型上，而不是在表达能力上。这使得翻译工作更接近"形式转换"而非"语义重建"。

第二，测试覆盖率必须足够高。 100万行代码的迁移，不可能靠人工逐一审查每一行。Sumner 的团队几乎完全依赖自动化测试套件来验证正确性。这意味着项目的测试覆盖率决定了迁移的可行性。

第三，需要有经验丰富的领域专家参与。 AI 负责执行翻译，但 Sumner 本人作为 Bun 的原作者，对每一个设计决策的背景和原因都有深入理解。当 AI 遇到模糊的翻译场景时，需要人工介入做出判断。AI 扩展了执行能力，但战略决策仍然需要人来做。

八、对开源生态的影响：语言竞争新格局

Bun 的这次迁移，对 Zig 和 Rust 两个社区都有深远影响。

对于 Zig 来说，这是一次声誉上的打击。Bun 是 Zig 最知名、生产依赖程度最高的项目之一。它的"叛逃"至少在表面上传递了一个信号：Zig 还不够成熟，不适合生产级项目。Andrew Kelley 的愤怒回应也反映了这种压力。不过，Zig 的核心价值主张——为底层开发者提供极致的控制力——并没有因为 Bun 的迁移而改变。对于内核开发者、嵌入式工程师和游戏引擎开发者来说，Zig 仍然是极具吸引力的选择。

对于 Rust 来说，这是一个强化其"系统编程首选"地位的机会。Rust 已经在 Linux 内核、Windows、Chrome、Android 等超级工程中得到认可。Bun 的迁移进一步证明了 Rust 在需要长期维护的大型项目中的优势。

对于整个社区来说，这个事件也提出了一个值得思考的问题：当 AI 使得语言迁移成本大幅下降时，编程语言的选择标准会发生什么变化？

过去，语言选择的一个重要考量是"迁移成本"——一旦选定了某门语言，转向其他语言需要巨大的工程投入。AI 改变了这个等式。如果100万行代码可以在11天内完成语言迁移，那么"选错语言"的代价将大大降低。这可能会鼓励开发者更大胆地尝试新语言，因为即使选错了，也有 AI 帮助修正。

九、开发者视角：这一事件对你的日常工作意味着什么？

作为一线开发者，我们能从这个事件中提炼出几条实用的启示：

启示一：AI 辅助编程已经进入了"大规模工程"阶段。 过去我们看到的 AI 编程案例，大多是写一个小函数、生成一段测试代码。而 Bun 的案例展示了 AI 在百万行级别工程中的可行性。虽然不是所有项目都需要这样的大规模迁移，但类似规模的代码生成、重构和翻译正在变得可能。

启示二：测试覆盖率是 AI 编程时代最重要的技术资产。 Sumner 的迁移方案之所以可行，根本原因是 Bun 有完善的测试套件。如果你的项目没有足够的测试，即使有 AI 帮助，重写也将是一场噩梦。投资测试覆盖率，就是投资未来应对变化的能力。

启示三：语言工具链的竞争格局正在重写。 Rust 的崛起已经不是新闻，但 Bun 的迁移代表了一个标志性事件：Rust 正式成为了"企业级系统编程"的首选语言之一。与此同时，Zig 面临着从"语言探索"向"生产可用"跨越的关键挑战。

启示四：选择工具时要考虑维护成本。 Bun 选择 Zig 的理由是合理的——2021年的 Zig 更适合快速迭代的个人项目。但随着项目成长，维护成本成为了主导因素。这提醒我们，技术选型不是一锤子买卖，需要持续评估工具是否仍然适合当前阶段。

结语

Bun 从 Zig 到 Rust 的迁移，是2026年技术圈最具标志性的事件之一。它不仅仅是一个语言迁移的故事，更是一面镜子，映照出 AI 编程的现状与未来、编程语言竞争的格局变化，以及开源生态中个人项目与商业利益之间的复杂关系。

11天、64个 Claude 实例、100万行代码——这组数字背后，是一个程序员与 AI 协作的全新实验。它的成功与否，不仅关乎 Bun 本身的命运，更关乎整个行业对 AI 编程边界的认知。

值得关注的是，这场迁移并没有结束 Zig 和 Rust 之间的争论，而是将争论推向了一个更深的层次：当我们有能力用 AI 完成任何语言的机械翻译时，什么才是真正重要的？架构设计？测试覆盖？还是开发者的判断力和审美？

这些问题没有标准答案。但可以确定的是，Bun 的故事才刚刚开始，而 AI 与编程语言的未来，正等待我们共同书写。

参考来源：

Jarred Sumner 官方博客声明（2026年7月8日）
Bun GitHub PR #30412（100万行合并）
Andrew Kelley Hacker News 评论（2026年7月）
Bun 官方性能基准测试报告（v1.4.0）
OSCHINA 报道《Bun 宣布将核心代码从 Zig 重写为 Rust》