Bun 在 2022 年凭借启动速度、内存占用和一体化工具链迅速走红。它以 Zig 构建，把运行时、包管理器、测试工具和构建能力放进一个产品中，也让不少团队开始认真考虑替代 Node.js。
三年多后，焦点从性能承诺转向了 Bun 1.4 的 Rust 重写及其延期。由于现有摘要没有给出重写范围、发布日期或具体技术阻塞，不能把延期简单归结为某个语言或某项实现失败。更值得讨论的是：当一个高速演进的运行时尝试更换底层实现时，真正困难的往往不是把代码翻译成另一种语言，而是在迁移过程中守住兼容性、性能和交付节奏。
重写运行时，难点不在语法转换
把 Zig 模块改写成 Rust，表面上是语言迁移，实际可能同时触及多个边界：
- JavaScript API 的可观察行为，包括异常类型、事件顺序和边界值处理。
- Node.js 兼容层，例如文件系统、网络、流和进程相关接口。
- 包管理器、测试运行器与构建工具之间的内部协议。
- 原生资源的生命周期，包括文件描述符、缓冲区和异步任务。
- 不同操作系统及 CPU 架构下的构建和发布流程。
Rust 的所有权模型可以在编译期阻止一部分内存错误，但它不会自动证明运行时行为与旧实现一致。一个在类型层面完全安全的新模块，仍可能改变任务调度顺序、错误信息或缓存策略，从而破坏现有应用。
因此，重写项目通常存在两张进度表：一张记录“多少代码已经迁移”，另一张记录“多少外部行为已经验证”。真正决定版本能否发布的是后者。
为什么高性能项目尤其容易低估迁移成本
Bun 的吸引力建立在性能和开发体验之上，这也提高了重写的验收门槛。
普通功能迁移只要结果正确即可；运行时迁移还要回答更多问题：启动是否变慢、常驻内存是否增加、高并发下尾延迟是否恶化、安装依赖是否仍然稳定，以及 Node.js 兼容性是否出现回退。
更麻烦的是，这些指标可能彼此冲突。为了减少内存分配而引入复杂缓存，可能增加实现和失效策略的风险；为了提高并发吞吐量而调整调度器，可能改变应用依赖的执行时序；为了快速补齐兼容接口，可能积累更多难以维护的特殊分支。
这也是为什么“改用 Rust”不能直接等同于“更快、更安全、更容易维护”。语言能提供工具和约束，但最终结果仍取决于架构边界、测试覆盖、性能测量和发布策略。
可以这样实践：为 Bun 升级建立双运行时验证
团队不必根据版本宣传或延期消息立即做出全量迁移决定。更稳妥的方法是让同一套业务测试同时运行在 Node.js 和 Bun 上，并记录正确性与性能基线。
下面的脚本假设项目已经安装 Node.js 和 Bun，并且 package.json 中存在 test 与 bench 脚本。运行前，把这两个脚本替换成项目自己的测试和基准命令。
#!/usr/bin/env bash
set -euo pipefail
printf 'Node: %s\n' "$(node --version)"
printf 'Bun: %s\n' "$(bun --version)"
printf '\n== Correctness: Node.js ==\n'
npm test
printf '\n== Correctness: Bun ==\n'
bun run test
printf '\n== Benchmark: Node.js ==\n'
time npm run bench
printf '\n== Benchmark: Bun ==\n'
time bun run bench
可以把它保存为 verify-runtimes.sh，然后执行：
chmod +x verify-runtimes.sh
./verify-runtimes.sh
为了让基准结果有意义，bench 不应只执行一次极短任务。可以用一个最小 HTTP 服务观察启动、吞吐和内存表现。下面的服务只使用 Web 标准风格的 fetch 入口，可直接用 Bun 运行：
const server = Bun.serve({
port: Number(process.env.PORT ?? 3000),
fetch(request) {
const url = new URL(request.url);
if (url.pathname === "/health") {
return Response.json({ status: "ok" });
}
return new Response("Not found", { status: 404 });
},
});
console.log(`Listening on http://localhost:${server.port}`);
运行并压测：
bun run server.js
curl -i http://localhost:3000/health
这个示例只能验证 Bun 自身的服务路径，不能证明真实应用完成了兼容迁移。生产评估还应覆盖数据库驱动、鉴权、中间件、文件上传、流式响应、定时任务和退出信号等实际路径。
不要让单次跑分快过兼容性检查
评估新版本时，可以维护一份明确的升级门槛：
- 锁定 Bun 版本，不在生产构建中自动追踪最新版。
- 对关键接口执行契约测试，而不仅是单元测试。
- 记录冷启动、P50/P95/P99 延迟、峰值内存和错误率。
- 检查原生依赖、安装脚本及 Node.js 专有 API。
- 保留 Node.js 回退路径，并确认构建产物可以重复生成。
- 在预发布环境持续运行，而不是只完成一次基准测试。
Bun 1.4 的等待提醒开发者：底层重写的价值不能只看提交数量或语言标签。对使用者而言，最重要的信号是可验证的兼容性、稳定的性能数据、清晰的发布边界，以及出现问题时能否快速回退。在这些条件满足之前，把 Bun 作为经过版本锁定和持续验证的运行时，会比把一次大版本升级当成必然进步更务实。