你以为 Bun 靠速度出名？今天它用 11 天把自己重写了——不是为了更快

铁锈·Rust工具链内容创作者 2026-09-06 11 阅读

说实话，大多数人听到”Bun 重写”第一反应是”又来了，性能又要涨了”。但你仔细看 Jarred Sumner 在 PR 里的说明，核心原因根本不是速度——是因为手写内存管理那套东西，把团队几年时间都烧在调试 Use-After-Free、Double-Free 和堆损坏上了。Rust 编译器的所有权检查 + Drop trait，相当于把这些 bug 在编译期直接变成编译错误，不用等到线上才爆出来。

这不是什么性能营销，这是一个工程师对自己工程债务的诚实清算。

背景：Zig 的代价

Bun 最早用 Zig 写，Zig 给了团队极致的底层控制——手动内存管理、comptime 元编程、零成本抽象。但控制是一把双刃剑。Zig 的贡献者池极小，工具链成熟度也远不如 Rust，最重要的是：Zig 没有稳定的标准库（2026 年了还是这样），和 JavaScriptCore 的垃圾回收混在一起，各种内存问题就出来了。

光一个 v1.3.14 版本就修了 13 个内存相关 bug。团队算了笔账：这些年花在排查这类 bug 上的时间和精力，够再写一个 Bun 了。

工程量：11 天，百万行，64 个 Claude 并行跑

官方工程博客（2026 年 7 月 8 日发布）披露了这次重写的细节：

时间线：

2026 年 5 月 3 日：开始重写
2026 年 5 月 14 日：PR #30412 合并，用了 11 天
2026 年 7 月 8 日：官方博客公开发布工程细节

规模：

源代码从单一庞大结构拆成约 100 个 crate，缩短编译时间
PR 合并时压缩了 6,755 个 commit，保留完整历史
11 天内共产出 6,502 个 commit
峰值时段每分钟 58 个 commit，单小时冲到 695 个
最高峰时每分钟写出约 1,300 行代码

AI 辅助：
团队把 Claude（Fable 5 预览版）当作主要代码生成工具，分四个阶段：

Phase A：Claude 生成移植指南和生命周期分析
Trial Run：3 个文件验证流程
Phase B-D：4 个 git worktree × 每组 16 个 Claude 实例（共 64 个并行实例），平行生成代码

建立了 LIFETIMES.tsv 和 PORTING.md 两份文件，把 Zig 语法模式一一对应成 Rust 生命周期标注。

结果：不是更快，而是更稳

这是最反直觉的地方。重写后的实测结果：

二进制体积：减小 3-8 MB
测试兼容性：Linux x64 glibc 上约 99.8%，所有平台全部通过原测试套件
性能：基准测试落在”持平到更快”区间，没有戏剧性的提升，也没有回退
内存泄漏：修复了数个长期积累的内存泄漏和 flaky tests

对于一个把”速度”当核心卖点的项目来说，”持平到更快”是个很克制的结果。但 Sumner 在 PR 里说得很清楚：这次赌的是长期稳定性和可维护性，不是短期跑分。

为什么这对前端工程师有意义

1. crates.io 生态红利

Bun 现在可以接入 crates.io 上超过 145,000 个 Rust crate。这意味着之前必须自己手写的东西，现在可能直接拽一个经过生产验证的库进来。对于 Bun 这种小核心团队，这是实实在在的工程杠杆。

2. 贡献者门槛降低

Rust 有比 Zig 大约 10 倍的 GitHub 仓库占比（3.1% vs 0.3%，JetBrains 2025 开发者调查）。更多工程师能看懂、能参与维护，这才是开源项目长期健康的关键。

3. 内存安全的工程意义

Microsoft 安全响应中心 2019 年的数据：约 70% 的 Chrome CVE 来自内存安全问题。对于一个运行不受信任 JavaScript 的运行时，内存安全不是锦上添花，是核心需求。

现在能用吗？

不能用于生产。 目前只有 canary 通道：bun upgrade --canary。团队明确说了，等优化和清理工作完成才会合入 stable。建议本地开发和 CI 里的 canary 构建先用起来，有 regression 直接提 issue 帮助稳定版本。

怎么判断要不要跟进

说白了：这次重写不是为了跑分更好看，是为了以后每次加功能不用再回头修内存 bug。11 天、百万行、64 个 Claude 并行——这种规模的工程切换，在前端工具链历史上不多见。值得持续关注。

评论区

0 条评论

登录后可评论。