Bun 1.4：Rust 重写后的第一次生产考验

Bun 1.4 在 2026 年 8 月 20 日进入稳定渠道。这是 Bun 主体从 Zig 移植到 Rust 后的第一个正式版本，距离百万行级重写合入 main 已经过了三个月。

发布页很长：新增 1517 个 Node.js 上游测试，修复超过 2900 个 issues，内存、CPU 和启动速度都有明显变化，还塞进了 WebView、Image、Markdown、Terminal、cron、parallel test 等一大批能力。真正影响生产决策的问题只有一个：现有项目能不能直接升？

我的结论很明确：可以尽快验证，不能承诺无损。普通 TS 服务和 CLI 很可能一次通过；Native addon、FFI、复杂网络、Windows 文件流、大型 monorepo 和重度并行测试需要单独过门槛。

这次 Rust 重写到底改了多少

Bun 1.3.14 是最后一个 Zig 主体稳定版。按 Git tree 统计，它有 1299 个 .zig 文件、11 个 .rs 文件；1.4.0 已经变成 0 个 .Zig、1523 个 .rs 文件。

重写 PR 的体量也很直观：新增约 100.9 万行，删除 4024 行，涉及 2188 个文件和 6755 个提交。官方披露的工作方式是大约 50 条 Claude Code 动态工作流持续运行 11 天，一个实现者配两个以上独立审查者，再由 fixer 应用反馈。

这次迁移保留了原架构和数据结构。JavaScriptCore 仍负责执行 JavaScript，uWebSockets、BoringSSL、SQLite、lsquic 等 C/C++ 组件也还在。Rust 覆盖的是 Bun 自己的 runtime glue、Node 兼容层、解析器、打包器、包管理器、测试器和 CLI。

官方在 7 月统计，约 78 万行 Rust 中有约 2.7 万行处在 unsafe block。这个边界很重要。Rust 的所有权和 Drop 能消掉一批 UAF、double-free、漏 free；JSC 指针、FFI、原生回调和 C allocator 仍要靠审计、ASAN、LeakSanitizer、Miri 与 fuzz。

为什么全量旧测试通过，还是修了大量回归

迁移前，Bun 1.3.14 的修复清单反复出现同一类内存问题：node:zlib 和 node:http2 的重入回调触发 UAF，UDP 与 Buffer 在 JS 回调里被 detach 后继续使用旧内存，TLS session、watcher、Scrypt 等错误路径漏释放。

换到 Rust 后，一批问题确实更早暴露。官方 7 月复盘列了 19 个已知移植回归，当时均已修复。源码层面的原因很有代表性。

React HMR 的一段 Zig assert() 带副作用，机械翻成 Rust debug_assert!() 后，release 构建把整个表达式删了，HMR graph 没更新。UTF-16 奇数字节在 Zig 中被截断，Rust 的严格 slice cast 直接 panic。resolver 里一个旧 off-by-one 过去在 ReleaseFast 没有边界检查，Rust release 把它确定地变成 panic。

还有一条更值得警惕：bun run --parallel 曾用虚假的 'static 生命周期保存局部 PackageJSON 字节，照样制造了 UAF。Rust 能否阻止内存错误，取决于生命周期是否真实建模。unsafe、裸指针和错误的 'static 可以把风险带回来。

官方早期 Rust port 还让 mimalloc 无条件成为 global allocator，ASAN/LeakSanitizer 一度看不到大量 native allocation。修复 allocator 配置后，团队才重新清理 bundler、parser、install、dev server 和 VM teardown 的泄漏。

我更看重这段历史。它说明团队的检测与修复能力在变强，也说明 100% 旧测试通过只覆盖已知行为。release-only 副作用、平台差异、极端输入和组合路径还得靠 canary 与真实项目补上。

1.4 的提升不只来自 Rust

Node.js 上游测试通过文件数从 1.2 的 1450 增加到 1.4 的 3743。node:http、fs、cluster、timers、zlib、vm、stream 达到 97%，node:quic 99%，events、trace_events、sqlite 100%。

这是一大步，官方也直接写明 Bun 仍未达到 100% Node 兼容。模块百分比无法证明某个框架、native addon 和生产流量组合一定没问题。

运行时数据同样亮眼。Bun 官方报告中，Claude Code 的 CPU p99 从 24% 降到 10%，p50 从 5.8% 降到 2.5%；Linux hello world 启动从 10.9ms 降到 5.1ms。HTTP 服务峰值内存相对 1.3 低 13% 到 48%。

上图是一个特定 Next.js App Router SSR 复现：1.3.14 持续增长，1.4 在 4000 个页面后稳定于 238MB，Node 26 为 410MB。它能证明这个复现被修掉，不能外推成所有 Next.js 服务都节省同样比例。

性能提升也不该全记在 Rust 头上。JavaScriptCore 改用 mimalloc、GC timer 和 Strong roots 调优、native Web Streams 与背压、WebKit 更新、SIMD、zlib-ng、跨语言 LTO 都参与了结果。

功能面则是一轮集中扩张。

WebView、Image、Markdown、Terminal、cron、JSON5、JSONL、XML、parallel/isolate/shard、React Compiler、CPU/heap Markdown profile、pm diff、audit fix、dedupe、prune 都在这个周期进入或完善。HTTP/3 仍是实验能力，官方直接提醒不要用于生产；Bun.markdown 的 HTML 输出也不会做 sanitize。

无损升级被哪些变化否定了

官方升级章节列了大量行为变化。光这份清单就足以否定普遍无损。

Native addon

Bun 报告 Node 26.3.0，NODEMODULEVERSION 变为 147。依赖 V8 ABI 的预编译 addon 需要 ABI 147 构建，N-API 包风险低一些，也要实际加载验证。

lockfile 与回滚

新生成的 bun.lock 默认是 v2，nested 或 version-scoped override 可能写 v3。1.4 能读旧 v0/v1，1.3 无法读新格式。迁移前删除 lockfile 再安装，会让回退入口一起消失。

环境变量与 FFI

Bun 作为 node shim 运行时不再自动加载 .env。bun:ffi 改成 engine-native 后，CString 变成普通字符串，.ptr 等旧接口消失。

配置与时间语义

YAML 改按 1.2 处理 yes/no/on/off，TOML parser 更严格，TLS hostname 和证书校验收紧。进程内 cron 从 UTC 默认改成本地时区，MySQL 的 DATETIME/TIMESTAMP 改按 UTC decode。

这些改动里有很多是在修旧行为、对齐标准或加固安全。对依赖旧行为的项目，修正照样会触发故障。

社区现在怎么评价 1.4

发布才一天，社区反馈适合看方向，样本还不够证明长期稳定。

Reddit 发布帖整体偏正面。有人直接使用 1.4，喜欢 bun test --parallel 和 --only-failures；也有用户已经把 Bun 跑在生产一年左右，认可低依赖和速度，同时保留稳定性担忧。

Hacker News 的分歧更明显。支持者喜欢电池全包和更小的供应链暴露面；质疑者担心一个二进制承担浏览器自动化、数据库、图片、解析器和测试器后，维护面持续扩大。更多争论集中在百万行 AI 辅助重写的 review 与发布治理。

一份独立 issue 数据研究统计到 8 月 10 日：明确指向 Rust canary 的 bug 报告从每周 5.92 增到 20.67，修复数从 2.58 增到 8.67。团队主动扩大 canary 暴露并鼓励报 bug，本身会推高报告数。这组数据能证明迁移期问题与修复吞吐一起上升，不能单独证明 Rust 版本质量更差。

稳定版发布后的问题要单独看

Canary 已修的 19 个回归不能继续算在 1.4.0 头上。正式版目前有自己的问题快照。

pnpm workspace 迁移曾在解析 overrides/catalog 时读已释放内存，修复已经进入 main，没进入 1.4.0。Windows 的 Bun.file() reject 路径会让进程在 await continuation 运行前 exit 0，修复 PR 仍开放。WebSocket async upgrade、build macro 等路径也有维护者确认的开放修复。

HTTP/2 负载停顿、bun test --isolate 配合 mock/spawn 的 EBADF/SIGSEGV 等问题给出了 1.3.14 对照，尚未完全闭环。它们不代表所有用户都会遇到，命中这些调用面的团队就不该跳过专项验证。

我不建议盯着首日 issue 总数下结论。搜索结果混有旧问题、文档和重复项。有一个流式 HTTP 问题看着像 1.4 回归，维护者复现后确认 1.3.14 才会截断，1.4.0 已经修好。跨版本复现、维护者确认和修复进入哪个 release tag，比标题情绪可靠。

升级方式

升级实验不需要穷举全部 API。只测项目实际使用的路径。

先保留当前 bun.lock，不要删除重建。固定两套精确版本后，跑同一组命令：

bun --version
bun --revision
bun install --frozen-lockfile
bun test
bun run build

有 alias、peer、override 或 catalog 的 monorepo，做三次干净安装并比较最终依赖树。用 HTTP/2、gRPC、WebSocket 或 streaming fetch 的服务，回放一段脱敏生产流量，看 response hash、reset、stall 和尾延迟。

Windows 项目覆盖不存在文件、空文件、大文件 stream、watch 与 spawn。使用 bun build --compile、worker、macro、native addon 或 FFI 的项目，要运行正式产物，改变 cwd 再跑一遍。

生产环境固定完整 patch 版本，先 CI 和 shadow traffic，再给 1% 到 5% 实例。保留 1.3.14 镜像、旧 lockfile 和旧构建产物。回滚命令也要提前验证：

curl -fsSL https://bun.sh/install | bash -s "bun-v1.3.14"

总结

Bun 1.4 的方向成立。Rust、LeakSanitizer、Miri、fuzz 和更大的 Node 测试集，让同类内存问题更容易被提前发现；兼容性、性能和工具链也有实打实的进步。

1.4.0 同时更换主体语言、Node 兼容目标、allocator、网络与流语义、包管理格式和大量内置 API。首日回归说明 canary 无法覆盖所有组合路径。

普通项目现在就可以试。生产服务要走双版本验证和灰度。命中 pnpm 大型迁移、Windows 文件流、HTTP/2/gRPC、FFI、standalone compile、并行隔离测试的项目，我会等对应修复进入具体 1.4.x tag，再扩大流量。