2026年7月的分叉：从旧代码库里挖出的Buz
2026 年 7 月 24 日，开发者 jazzzooo 在社区公开发布了实验性项目 Buz。该项目基于 Bun 在 2026 年初放弃 Zig 架构、转向 Rust 重构前的最后一个 Git 提交。作者使用上游主线（upstream master）版本的 Zig 重新编写了整体构建工程，尝试恢复这个已被官方放弃的代码脉络。
Buz 的核心目标是提供一个代码库更加干净的 Bun 替代品。在最新的构建测试中，Buz 实现了低于 1 秒的增量编译速度。这说明在合理规划依赖图的前提下，Zig 的原生构建系统完全能为多语言混合的大型 C/C++ 基础设施提供即时反馈。
这一分叉并没有停留在简单的编译适配层面。作者在复活项目的同时，展开了一场名为「deslop the codebase」的代码清理行动，将原代码库中积攒的残留模块进行拆解与剔除。
11000行死代码暴露的重构前夜
在整理旧版 Bun 的 Zig 代码库过程中，Buz 团队一次性删除了超过 11,000 行无用代码。这些代码涵盖已被废弃的系统调用封装、重复定义的类型声明以及早期实验性功能留下的调用存根。
11,000 行死代码占到了原 Zig 版本核心业务逻辑相当大的比例。这说明在早期高速迭代阶段，为了快速覆盖 Node.js API 兼容性，项目不可避免地积累了大量未及时清理的中间过渡代码。
快速功能交付与代码库演进之间的失衡，最终会在架构重构前夕集中显现。当新增功能的维护成本超出代码收益时，清除冗余代码或更换语言基础设施便成了项目演进的必然选项。
全部纳入build.zig：Zig构建系统的工程范式
除了清理死代码，Buz 最大的技术变更是将包括 vendored JavaScriptCore（JSC）在内的全部 C++ 源码完全交由 build.zig 统一调度。以往此类项目通常依赖 CMake 或复杂的 Makefile 链条来协调 C++ 引擎与外层语言的编译过程。
通过 Zig 原生声明式构建图来管理 JSC 的编译选项与链接路径，Buz 将庞大的第三方 C++ 依赖完全融入了统一的编译流水线。单次改动后的增量编译时间被压缩至 1 秒以内，这使得开发者在修改 C/C++ 与 Zig 交互层代码时，能够真正做到修改一行就即时验证结果。
摆脱外部构建工具链后，跨平台交叉编译的配置复杂度大幅降低。Zig 将编译器本身兼做构建工具的设计，在这个混合语言项目中展现出了极高的工程集成效率。
重构拉锯战：生态诉求与代码洁癖的冲突
Bun 在 2026 年初选择从 Zig 转向 Rust，主要受制于 Zig 语言尚未完全稳定、破坏性更新频繁以及 Rust 生态在人才招聘和第三方库丰富度上的优势。在商业化公司主导的大型工程中，选择生态成熟度更高的 Rust 能够降低团队扩展的工程风险。
Buz 则是技术社区对另一种工程审美的坚持。它选择留在 Zig 体系内，借助 Zig 简洁的语法结构和强力的构建工具来消除过度设计的抽象层。作者将 Rust 版 Bun 的全部新测试用例导入 Buz，虽然当前大部分测试尚未通过，但这为追赶上游功能设定了明确的技术基准。
商业项目需要向交付效率和人才供给妥协，而社区分叉则保留了探索极简架构的可能性。两种路线的选择差异，体现了不同的工程侧重点与发展目标。
当弃置的分叉变成技术实验的对照组
Buz 目前远未达到生产可用的成熟度，但它作为对照组的技术价值已经显现。它证明了使用 Zig 构建系统盘活大型 C/C++ 混合工程的可行性，低于 1 秒的增量编译体验显著提升了底层开发的反馈速率。
与此同时，Buz 删掉的 11,000 行死代码清晰展示了快速迭代阶段所付出的代码质量代价。这场针对废弃代码库的复活尝试，既是一次关于编译效率的工程试验，也是一份关于技术债务积累的直观样本。
参考链接：
- Ziggit 讨论：Buz - A drop-in replacement for Bun using modern Zig
- Hacker News 讨论 (108 points, 73 comments)
