Bun最新一轮的bug修复清单读起来更像事故报告:node:zlib流重置时的堆use-after-free,http2重入回调触发哈希表rehash导致的悬空指针,UDPSocket发送时ArrayBuffer被回调提前释放引发的越界写,还有一处TLS会话缓存每次调用都会漏掉约6.5KB内存的老毛病。这些问题攒得太久,Bun给出的答案不是继续打补丁——是把整个运行时从Zig推到重写台,换成Rust。
更值得留意的是操刀方式。Bun已于2025年12月被Anthropic收购,这次重写大量借助了Anthropic预发布的Claude Fable 5。一个刚被大模型公司买下的系统级项目,用买家自家还没公开的模型重写自己最底层的运行时代码,这本身就是一场没有先例的实验。
Zig的锅,原作者不背
Bun的起点是2021年,创始人用Zig从零重写了esbuild的Go代码,一年内独立做出了打包器、包管理器、测试运行器和Node兼容层,野心大到离谱。靠着这份野心,Bun现在每月下载量超过2200万次,Claude Code、OpenCode把它当默认运行时,Vercel、Railway都做了原生支持。
问题出在Zig不做自动内存管理,却要和JavaScriptCore这种带垃圾回收的引擎混着用。手动释放的内存和GC对象混在一条调用链里,defer能管住普通的清理,管不住"这块GC指针到底谁在引用"这种问题。
手动内存和垃圾回收混用,本来就没几门语言天生为它设计。
这是Bun博客自己的判断,不是甩锅,是承认这类场景太少见,连风格指南都很难兜底。
一次性重写,靠审查循环兜底
Bun这次没做渐进式重写——先留一半旧代码、慢慢替换那种做法,团队判断这样反而拖得更久。选择的是全量重写:先生成一份Zig到Rust的模式对照表,再机械地把每个.zig文件转成.rs,最后跑通整套用TypeScript写的、不依赖运行时语言的测试集。
真正的把关手段是拆开上下文的对抗审查:写代码的Claude实例不参与审查,审查的Claude实例只负责找茬,默认代码是错的。这套流程跑了约50个动态工作流,持续了11天。
官方发文之前,外界已经看了两个月
Bun把这套过程写成博客发出来,读起来像是一次内部单方向的技术决定。实际时间线不是这样。
早在博客发布前约两个月,The Register就已经报道过Anthropic旗下Bun团队在试验从Zig迁移到Rust。这期间,Reddit的r/rust社区已经在讨论具体的重写分支和合并过程,Hacker News上也有人转述过一个"99.8%测试通过率"的数字——但这个数字来自二次转述,不是Bun或Anthropic官方文章直接确认的。
社区反应也不是一边倒。r/Zig那边偏防御,不少人把这次转向解读为对Bun工程决策的批评,不是Zig语言本身出了问题;r/programming则更多是调侃,顺带担心外界把重写的完成度估得太高。
换语言不是免死金牌
真正戳破简单叙事的是GitHub上的具体issue:新的Rust代码库里,依然存在unsafe代码块被不当使用、可能引发未定义行为的地方。这一点很关键——Rust的安全承诺建立在编译器强制检查上,一旦代码大量走unsafe分支,这层保护就形同没有。
Bun自己也承认,这次重写走的是"先机械转译,再逐步减少unsafe"的路子,不是一步到位的idiomatic Rust。也就是说,原来那份触目惊心的bug清单,理论上被压缩到了unsafe代码块这个更窄的范围里,但没有被清零。
- 结论.这次真正被检验的不是语言选不选Rust,是Anthropic自己的模型能不能扛住高风险系统级重写的活。
- 风险.unsafe代码块用得不对,use-after-free和内存泄漏一样能在Rust里原样复现。
Bun的下载量、生态位置、被收购后的资源,都让这次重写有底气一次性做完。但外界能验证的,只有测试通过率的转述数字和几个GitHub issue。官方要是真想把这份信任坐实,该拿出的是重写前后的崩溃率对比,不是一篇讲清楚流程的博客。