Buz 把 Bun 重建压到 1 秒内，但一个人的分支能追多久？

Bun 的一个分支，把增量重建压到了 1 秒以内。开发者 jazzzooo 从 Bun 转向 Rust 前的最后一次提交出发，拉出一个仍在施工中的项目：Buz。

这个数字很抓眼，但也最容易把讨论带偏。亚秒级构建能改善贡献体验，却不能证明运行时已经稳定。Buz 目前仍有大量测试失败，作者也明确表示，它离生产可用还很远。

Buz 把构建系统重新收拢了一遍

Buz 试图继续使用现代 Zig，并把原本分散的构建关系收进统一的 build.zig。构建图和项目内置的 JavaScriptCore 也纳入其中，因此 Zig 的增量编译可以覆盖更多依赖关系。

按照作者公布的结果，增量重建时间可以低于 1 秒。这是作者自述，尚不能当作跨机器、跨平台的独立基准。编译器版本、缓存状态、硬件和具体改动范围，都会影响结果。

项目目前可以压缩成四件事：

这里还有一个容易被标题遮住的事实：Bun 从来不是“只靠 Zig”或“换成 Rust”就能讲清楚的项目。它的核心能力还依赖 JavaScriptCore、uWebSockets、Brotli 等 C/C++ 组件。语言只是表层选择，真正麻烦的是跨语言边界、平台差异和长期补丁维护。

Buz 的价值，目前更接近一份激进的工程整理方案。它证明了一套更集中、更适合增量编译的构建方式可能走得通。至于能否成为替代品，现有证据还不够。

测试失败，比编译快慢更接近真问题

JavaScript 运行时的兼容性，不是“能执行几段脚本”这么简单。包管理、Node.js API、N-API 原生扩展、网络协议、文件系统行为和边界错误，都可能让应用在迁移后悄悄变样。

Buz 还面临一层更难处理的结构性问题：它选择了一个会继续前进的上游作为兼容目标。

上游增加接口、修复语义、调整底层依赖，分支就要判断哪些改动该跟、怎么跟。追得慢，兼容承诺会迅速过期；追得太紧，清理出来的代码又可能重新背上上游的复杂度。分叉项目常见的困境就在这里：第一次删代码很痛快，之后每一次合并才是真正的账单。

JSC 与 V8 的差异也不能靠 API 名称抹平。N-API 能提供一部分稳定边界，却无法自动消除引擎行为、垃圾回收、调试接口和原生模块假设上的差别。Buz 若要兼容 Bun，最终必须拿测试矩阵说话：哪些平台通过，哪些 Node.js API 可用，哪些原生扩展会失败，性能回退发生在哪里。

“创业难，守成更难。”放到开源分支上，守成就是持续跑测试、定位回归、追安全更新，并在上游改变方向时重新做取舍。构建快，只是让这份苦工便宜一点。

单人、LLM 与上游追赶，才是项目的压力测试

作者广泛使用 LLM 辅助开发，并暂时不接受人工编写的贡献。作者还对部分既有代码作出“AI slop”之类的激烈评价。这是作者的定性，不是经过独立代码审查后得到的结论。

这套治理方式短期确实有优势。一个人控制修改节奏，可以迅速删除死代码、统一风格，也不用为每个补丁付出沟通成本。原型期尤其有效。

代价同样具体。运行时项目需要大量平台复现、回归判断和兼容性知识。LLM 可以加快改写，却不会替项目承担版本承诺；拒绝人工贡献，则把审查、测试、上游同步和发布责任进一步集中到一个人身上。代码行数降了，组织风险反而可能升高。

我更在意的正是这一点：Buz 能不能把一次性的清理成果，变成重复执行的维护制度。真正有说服力的进展不会是一张亚秒级截图，而是连续版本都能交出可复现构建、公开测试结果、兼容范围和升级记录。

对 Bun 与 Zig 贡献者，Buz 现在适合研究构建图、增量编译和代码清理方案，也适合在隔离环境中复现实验。它还不适合承载生产服务。

依赖 Bun 兼容性的开发团队更不该急着迁移。现实动作是先列出自己的 Node.js API、N-API 模块、部署平台和包管理流程，再逐项跑测试。只要其中一项依赖模糊，亚秒级重建就省不回迁移后的排障时间。

Buz 已经指出了 Bun 工程里可能存在的构建负担，这一点有技术价值。但兼容运行时靠的是漫长而枯燥的守约。一个人的速度可以很快，一个项目的信用只能慢慢积累。