Bun 上生产的决策记录：快是真的，但“快”不是迁移的理由

背景： 一个中等规模的 API 服务，Node.js 22 LTS，Express + TypeORM，日常 QPS 峰值约 3000，团队五个人。看到 Bun 的基准数据——合成 HTTP 测试 48243 req/s 对 Node 的 25181 req/s——决定做一个两周的迁移评估。

第一周：本地开发体验确实好。 bun install 的速度、内置测试运行器、直接跑 TypeScript 不用配 ts-node 或 tsx，这些在本地迭代中的体感提升是真实的。bun test 替代 Jest 之后，CI 里测试阶段的耗时下降了大约 40%。

第二周：生产评估暴露了真正的成本。 第一个问题是原生模块。项目依赖一个图像处理的 C++ addon，Bun 在 2026 年对原生模块的支持已经比早期好很多，但这个特定依赖的 ABI 兼容性仍然需要验证，最终不得不把它换成一个纯 JS 实现，性能有所下降。第二个问题是部分 Node 特定 API 的行为差异，async_hooks 和 diagnostics_channel 在 Bun 上的实现细节不同，我们的 APM agent 依赖这些接口做上下文传播，迁移后 trace 出现了断点。第三个问题更实际：生产目标平台是一个只跑 Node 的 Serverless 环境，Bun 无法作为运行时。

决策：不迁移生产，但保留 Bun 做本地开发和 CI 测试。 理由不是“Bun 不好”，而是迁移的收益集中在开发体验，成本集中在生产环境的生态兼容性和平台约束。对于一个依赖原生模块、APM 深度接入、部署平台锁定的服务，切换运行时的收益不足以覆盖风险。同期有一个纯 TypeScript、无原生依赖、部署在自有容器里的小服务，迁移到 Bun 之后冷启动和内存表现确实更好，那个服务留在了 Bun 上。

一年后的回顾： 2026 年的运行时格局已经比较清楚。Node 的优势是“存量确定性”——所有托管平台支持、所有可观测性厂商有 agent、冷门包只在它上面测过。Bun 的优势是单工具链和迭代速度，适合新项目或边界清晰的服务。Deno 的差异化在严格沙箱和 Web 标准优先。三者不是替代关系，是按“生态风险容忍度”和“平台约束”分层。运行时选型的第一问不是“谁快”，而是“我的依赖、部署平台和可观测性栈，在目标运行时上有没有未经验证的假设”