2026 年 7 月 8 日JavaScript 运行时 Bun 的创始人 Jarred Sumner 在官方博客发布了一篇震动技术圈的声明经过 11 天的高强度工作Bun 全部 Zig 代码被机械式转换为 Rust新版 v1.4.0 已进入 canary 通道。这不是一次普通的版本更新而是一场把“预计需要一个小团队一整年”的语言级重写压缩到不到两周的工程实验主导者只有一名工程师外加预发布版 Claude Fable 5。这件事之所以值得前端与基础设施开发者认真拆解不在于“AI 又干了件大事”的猎奇而在于它把两个长期困扰系统级软件的问题同时摆上了台面第一当一个混用“垃圾回收”与“手动内存管理”的运行时膨胀到 53 万行时内存安全 bug 为什么会从偶发变成结构性顽疾第二当重写的规模大到任何人工团队都无法在合理时间内完成时怎样用一套可验证的工程流程让百万行 LLM 生成代码“敢于合并”。本文不重复新闻通稿而是依据 Bun 官方博客、GitHub 仓库与多方媒体报道拆解这次迁移背后的设计决策为什么是 Rust 而非 C/Go、机械移植策略为何能成立、对抗式审查循环如何堵住 LLM 代码的质量漏洞以及迁移后的实测收益与尚未解决的局限。一、53 万行 Zig 的稳定性困境为什么必须换语言Bun 诞生于 2021 年 4 月Jarred Sumner 最初只是把 esbuild 的 Go 代码逐行移植成 Zig看中的是 Zig 极简的语法与零开销抽象。凭借一站式集成JS/TS/CSS 转译打包、npm 兼容包管理器、Jest 风格测试运行器、完整 Node.js 模块解析、HTTP/WebSocket 客户端Bun CLI 月下载量已突破 2200 万Vercel、Railway、DigitalOcean 原生适配Claude Code、OpenCode 等工具将其作为默认运行时。但规模本身就是问题。据官方博客披露不含注释的 Zig 代码已达 535,496 行中文媒体报道总文件数 1448 个、含注释与空行约 78 万行。Jarred 在博客中直接贴出 v1.3.14 修复的一批典型高危 bug根因高度一致——都是“手动管理内存”与“JS 垃圾回收”混用时的生命周期失控node:zlib异步.write()仍在进行时调用.reset()触发 heap-use-after-freenode:http2重入回调如session.request()写在 timeout listener 里引发哈希表 rehash使内部流指针失效UDPSocket.send()中用户valueOf()/toString()回调在捕获负载与实际发送之间分离了 ArrayBuffercrypto.scrypt输出缓冲分配失败时回调与受保护的口令/盐缓冲永不释放造成泄漏CSS 解析器在background-clip带厂商前缀且多层背景时双重释放tlsSocket.setSession()每次调用泄漏一个 SSL_SESSION约 6.5 KB。这些不是孤立失误。Jarred 坦言团队已经叠加了远超多数项目的防御手段给 Zig 编译器打补丁加入 Address Sanitizer、每次提交都跑 ASAN、Windows 上发行 ReleaseSafe 构建、用 V8/JavaScriptCore 同款 fuzzer Fuzzilli 7×24 小时模糊测试、外加大量端到端泄漏测试。但模糊测试发生在代码合并之后、CI 发生在推送之后、ASAN 发生在运行时——所有反馈都太晚只能在 bug 出现后被动修补。问题的结构性根源在于语言本身。Zig 像C一样不替你管理内存没有构造/析构函数清理工作要在每个调用点用defer/errdefer显式写出。官方博客用一张对照表点明了三种语言的清理机制差异Language Cleanup mechanism Zig defer, errdefer 显式靠人记得写 C ~Destructor, Move 隐式析构但靠规范约束 Rust Drop 隐式编译器强制当一个*T被传给许多函数时到底哪一处负责释放哪些函数在调用后还要引用这块内存Bun 现有的做法是“arena 生命周期 引用计数 极度仔细”的混合体。Jarred 指出理论上可以用风格指南如 TigerBeetle 的 TigerStyle、Google 三万字的 C 规范来约束但风格指南的软肋是“靠代码审查尽力执行”。而 Zig 没有运算符重载强行引入自研智能指针会让代码退化成下面这种难看的形态fn foo(a_ptr: SharedPtr(TCPSocket)) !void { const a: *TCPSocket a_ptr.get(); defer a_ptr.deref(); const b try do_something_with_a(a); defer b.deref(); // ... }对比原本符合 Zig 直觉的写法自研智能指针牺牲了人体工学却换不来 Rust 那样的编译期保证。这正是团队最终放弃“在 Zig 里加智能指针”路线、转向整体迁移的根本原因。二、为什么是 Rust 而非 C 或 Go在选定 Rust 前团队认真评估过 C/C 与 Go。Bun 约 20% 的代码本就是 C还内嵌了 JavaScriptCore、uWebSockets、lshpack/lsquic、BoringSSL、SQLite 等 C/C 库——切到 C 能删掉大量extern C桥接代码、也能拿到析构函数。但 C 依旧依赖“风格指南 代码审查”来防内存错误即便有 ASAN内存损坏与泄漏仍会发生。Rust 的吸引力可以用一句话概括这也是官方博客的核心论点在 safe Rust 中那一长串 use-after-free、double-free、“错误路径上忘记释放”全部变成编译错误并通过Droptrait 实现 RAII 式自动清理。编译错误是比风格指南更好的反馈回路——它把“内存有且仅释放一次”这件事从人的注意力转移到了类型系统。值得注意的是这与同期 TypeScript 7.0 选 Go 而非 Rust 的逻辑形成对照。TypeScript 负责人 Ryan Cavanaugh 曾解释Rust 的所有权模型禁止没有重大变通的循环数据结构而 TypeScript AST 充满循环引用用 Rust 需重新设计编译器数据模型那是数年工作且无法保证兼容Go 移植只用了约一年并保持语义一致。两件事说明同一规律选语言不是选“最强”的而是选“约束恰好匹配痛点”的——Bun 的痛点是内存生命周期Rust 的 Drop 正中靶心TS 的痛点是并行与原生速度且 AST 大量循环Go 的 goroutine 与宽松所有权更合适。三、机械移植策略让测试套件成为迁移的“锚”语言级重写在软件工程里素来是高风险决策。Jarred 自己也承认“历史上重写通常是个糟糕的主意”。降低风险的唯一现实路径是做一次行为零改动的机械移植mechanical port不重构架构、不动业务逻辑、不改性能特性只把 Zig 逐文件翻译成 Rust并用同一套测试套件验证。这条策略能成立关键前提是一个常被忽视的工程决策——Bun 的测试套件用 TypeScript 编写与运行时的实现语言解耦。这意味着迁移 Rust 后百万级断言的测试可以原样跑在新生成的二进制上测试本身不需要被重写。媒体披露的细节进一步印证了移植的“机械”程度约 1448 个 Zig 文件被转成 100 个 Rust crate子仓库期间要攻克超过 16000 个编译错误与循环依赖问题并产出PORTING.md、LIFETIMES.tsv等迁移文档供后续贡献者参照。这种“先机械翻译、再渐进重构”的两段式策略值得任何考虑大规模语言迁移的团队借鉴。官方博客明确先让 Rust 版“看起来像从 Zig 转译出来的”等 v1.4 上线后再逐步减少unsafe用法、向地道 Rust 靠拢。把“功能等价”与“代码地道”拆成两个独立阶段避免了既要保兼容又要写漂亮代码的双重风险。四、对抗式审查循环让百万行 LLM 代码“敢于合并”11 天、百万行新增代码、单人主导——这类 PR 最大的挑战不是“写出来”而是“怎么建立合并的信心”。官方博客把方法论讲得很透核心是一个被显式建模的“写代码—审查”循环// 官方博客给出的伪代码非真实代码 let task; while ((task todoList.pop())) { const result task(); const feedback await Promise.all([review(result), review(result)]); await apply(feedback, result); }Jarred 用约 50 个 Claude Code 动态工作流持续跑了 11 天每个工作流都是上面这样的循环分别负责生成迁移指南、逐文件机械移植、修复每个 crate 的编译错误、让bun test/bun build跑通、让全部测试通过、以及多轮大型重构与清理。真正有意思的是“对抗式审查”adversarial review的隔离设计。它的灵感来自人类工程实践写代码的人想合并会有确认偏误审查的人只找问题。于是 Claude 也被拆成两个独立上下文——1 个实现者配 2 个以上对抗审查者实现者不审查、审查者不实现。审查者拿到的是纯净的 diff并被要求“假设这段代码是错的”穷尽地找出 bug 与失效理由。官方博客晒出了对抗审查在合并前真实捕获的三个 bug且每个都带 commit 哈希作为佐证。这三个 bug 全部能编译通过、看起来都合理却藏着致命缺陷Bug 1异步 close 的 use-after-free double-freecommitf0a454376c7。代码把Boxuv::Pipe交给 libuv 异步关闭但Box在 match 分支结束时就被 drop 了libuv 还持着已释放的指针回调时又释放一次for stdio in [spawned_stdout, spawned_stderr] { match stdio { StdioResult::Buffer(mut pipe) { // pipe: Boxuv::Pipe — hand it to libuv to close pipe.close(Subprocess::on_pipe_close) } StdioResult::Fd(fd) fd.close(), StdioResult::Unavailable {} } } // 修复用 Box::leak 让所有权转移给 libuv避免提前 drop // Box::leak(pipe).close(Subprocess::on_pipe_close)Bug 2trunc还是floorcommit7cc88f00141。把 f64 秒拆成 timespec 时用trunc对 1970 年前的负数时间会算出负的 nsec这是非法 timespecfloor才能保证 nsec 落在[0, 1e9)let sec t.trunc(); TimeLike { sec: sec as i64, nsec: ((t - sec) * 1e9) as i64, } // 修复let sec t.floor(); 并对 nsec 取 .round()Bug 3unwrap_or的急切求值commit90111846a14。color-mix()缺省百分比时unwrap_or会急切求值参数表达式导致另一侧百分比缺失时直接 panic应改用惰性的unwrap_or_elselet p1 first.percentage.unwrap_or(1.0 - second.percentage.unwrap()); // 修复unwrap_or_else(|| 1.0 - second.percentage.unwrap())这三个例子极具教学价值它们恰好对应内存生命周期、数值边界语义、求值时机三类典型陷阱且都不是“能跑就行”能发现的。对抗式审查的价值在于——当某个流程产出的代码出问题时去修流程而不是手动修代码这样新生成的代码就不会再犯同类错误。五、迁移结果内存、体积、性能的实测变化完成迁移后Bun 在多个维度出现可测量的改善。以下数据来自中文技术媒体的报道读者应以官方后续发布的基准为准但可作为量级参考。内存占用是改善最显著的维度。据媒体报道原 Zig 版本单次构建泄漏约 3 MB连续 2000 次构建后内存占用高达 6745 MBRust 版本同等条件下仅 609 MB且原生内存分配可被 LeakSanitizer 完整追踪。这与前文分析的“Drop 自动清理修复错误路径泄漏”完全吻合。安装包体积缩减约 20%通过代码折叠、ICU 数据清理、zstd 延迟解压等优化Linux 版从 88 MB 降至 70 MBWindows 版从 94 MB 降至 76 MB。性能呈小幅提升约 2%–5%Linux Xeon 铂金平台测试HTTP 服务吞吐从 169.6k req/s 升至 177.7k req/s4.8%Next.js 构建从 13.62s 压缩至 13.03s4.5%Claude Code 启动速度优化约 10%。需要强调的是机械移植策略本身不以性能提升为目标这些收益更多来自 Rust 编译器优化与更干净的资源管理而非刻意调优。稳定性方面新版一次性修复了旧版本 128 个顽固 bug测试套件在 Linux/macOS/Windows 全平台通过。同时官方承认仍有约 4%约 1.3 万处unsafe代码残留计划在后续版本持续清理为地道 Rust 写法。六、局限性与争议把这次迁移神化是不诚实的。它在 Hacker News 引发两极讨论质疑声同样有力。第一是“vibe coding”的可维护性担忧。百万行 LLM 生成代码即便测试全绿长期可维护性仍存疑。官方博客自己也承认当前 Rust 代码“看起来像从 Zig 转译出来的”仍有约 4% 的unsafe与非地道写法需要后续多轮重构。这意味着 v1.4.0 更像是一个“功能等价但风格未定型”的起点而非终点。第二是动机争议。有观点认为这是 Anthropic 借 Bun 刷 AI 能力案例的营销行为也有 Zig 支持者指出同等人力投入下优化 Zig 也能达到相近效果换语言未必必要甚至有传闻称此举与 Zig 社区拒绝 LLM 贡献的路线冲突有关。这些说法目前缺乏直接证据但提示读者单一来源的叙事需要保留判断。第三是数据溯源问题。本文中“100% 测试通过率”“1448 文件”“约 16.5 万美元 API 成本”“59 亿输入 token”等数字多来自中文媒体转述官方博客确认了 535,496 行 Zig、11 天、约 50 个工作流、100 万行 PR、预发布 Claude Fable 5 等核心事实但完整的成本与通过率明细需以官方后续披露为准。第四是一个值得玩味的细节截至本文核查时Bun 在 GitHub 主分支的 README 仍写着 “Its written in Zig and powered by JavaScriptCore”而仓库中已并存Cargo.toml、Cargo.lock、rust-toolchain.toml与CLAUDE.md、.claude/目录。这反映出迁移处于“主分支已并入 Rust、稳定版仍以 v1.3.xZig为准、v1.4.0 走 canary”的过渡态文档与代码尚未完全同步普通用户通过bun upgrade --canary才能尝鲜。七、结论与启示抛开争议Bun 这次迁移给前端与基础设施开发者留下三条可复用的工程经验。其一测试套件的语言无关性是大规模重写的真正杠杆。正因为它用 TypeScript 写测试迁移后百万级断言原样复用才让“机械移植 全量验证”成为可能。任何可能面临技术栈演进的系统级项目都应刻意把测试与实现语言解耦。其二编译期约束优于风格指南。Bun 那一长串 use-after-free/double-free/泄漏根因是 Zig 把内存生命周期交给了人的注意力Rust 用Drop把它交给类型系统后这类错误直接变成编译错误。选语言时应优先让语言的约束对准项目最痛的那类 bug。其三对抗式审查循环是 LLM 大规模生成代码的质量底线。1 个实现者 2 个以上独立上下文的对抗审查者加上“出问题修流程而非修代码”的原则把“敢于合并百万行 AI 代码”从赌博变成可重复的工程动作。这套模式不仅适用于语言迁移也适用于任何 LLM 参与的大型重构。Bun 的 Rust 版仍在 canary 阶段unsafe清理与地道化是后续漫长工作。但它已经证明在 2026 年一次原本需要一整年的语言级重写可以借助“语言无关测试 机械移植 对抗式审查”在 11 天内完成且可验证。这对前端工具链“全面换芯”的浪潮——TypeScript 7.0 选 Go、Astro 7 与 Vite 8 选 Rust——是一个有力的注脚。相关开源仓库与官方资料Bun 仓库GitHub - oven-sh/bun: Incredibly fast JavaScript runtime, bundler, test runner, and package manager – all in one · GitHub官方博客“Rewriting Bun in Rust”Rewriting Bun in Rust | Bun Blog作者整理的前端工具链实践合集GitHub - wangzifan396-wzf/TW: AI 可视化实验室集 · 176 个交互式项目 · 1408 模块 · 零外部依赖 · 纯 HTML/CSS/JS SVG · 覆盖 AI/ML、CS 系统、计算理论、交叉学科全谱系 · GitHub