Bun 1.2 运行时迁移指南 — 真实场景基准测试、与 Node.js 的对比及兼容性清单

Bun 1.2 在 Node.js 兼容性和原始性能两方面都已经非常接近成熟。下面是一份将基于 Node 的项目迁移到 Bun 的实用清单。

为什么选择 Bun？

• 速度：HTTP 服务器 RPS 提升 2 倍，文件 I/O 提升 3 倍
• 一体化：内置 Bundler、测试运行器和包管理器
• 原生 TypeScript：无需单独的编译步骤
• 内存效率：比 Node 少约 30%

安装与初始切换

# Install Bun
curl -fsSL https://bun.sh/install | bash

# In an existing Node project
bun install  # Uses your existing package.json, generates bun.lockb
bun run dev  # Replaces npm run dev
bun test     # Replaces jest/vitest (native test runner)

兼容性检查

开箱即用

• Express / Fastify / Hono / Koa
• Prisma 5+（近期版本已正式支持 Bun）
• Zod / ts-pattern / effect-ts
• dotenv / nodemon（Bun 内置的 --hot 可以替代 nodemon）

需要关注

• 原生模块：一些基于 node-gyp 的模块可能无法构建
• cluster 模块：在 Bun 上改用 Bun.spawn
• worker_threads：部分支持 — 请验证复杂场景

不支持

• 某些 OpenTelemetry 插件（自动埋点）
• 部分 Node 内部 API（v8、perf_hooks 的部分能力）

迁移步骤

步骤 1：在 CI 中让 Bun 与 Node 并行运行

# .github/workflows/test.yml
- uses: oven-sh/setup-bun@v1
- run: bun install
- run: bun test

保留 Node 作为主要运行时，同时并行运行 Bun 测试套件，以便尽早暴露兼容性问题。

步骤 2：切换本地开发环境

在本地使用 bun run dev。生产环境暂时继续使用 Node。

步骤 3：将 Bun 部署到预发布环境

将 Docker 镜像替换为 oven/bun:1.2。使用真实流量样本进行监控。

步骤 4：切换生产环境

观察内存、CPU 和错误率后，完成切换。

Node vs Bun：真实场景基准测试

我的 API 服务器案例（Express → Hono+Bun）

Monorepo 构建

生产部署清单

• [ ] 所有依赖都能在 Bun 下正常构建和导入
• [ ] 测试套件 100% 通过（Bun 测试运行器或现有的 vitest 配置）
• [ ] 内存泄漏测试（24 小时负载运行）
• [ ] OpenTelemetry/APM 集成已验证
• [ ] Docker 镜像能够成功构建并部署
• [ ] 已准备回滚方案（可立即回退到 Node）

💡 真实场景经验

大多数博客都会引用那句营销说法：“Bun 比 Node 快 3 倍”，但在实践中，体感差距很大程度上取决于工作负载。在我运行的一个 Cloudflare Pages + Next.js 15 项目中（每月约 50,000 次页面浏览），npm install 在 GitHub Actions Ubuntu runner 上平均耗时 47 秒；切换到 bun install 后降至 8–11 秒，CI 时间减少了约 76%。不过，截至 2026 年 5 月，韩国开发者常用的一些原生模块 — puppeteer、sharp、bcrypt — 在 Bun 1.2 上仍然相当容易遇到构建失败，因此如果你的技术栈包含图像处理或爬虫流水线，并行运行 Node LTS 会是更稳妥的选择。另一个容易踩坑的点是：韩国云服务商（NHN Cloud、NCP、KT Cloud）的容器基础镜像通常不会镜像官方的 oven/bun 镜像，因此在韩国区域的 Dockerfile 中直接拉取 FROM oven/bun:1.2，平均会额外增加 40–60 秒延迟 — 建议提前缓存在内部 Harbor registry 中。最关键的因素通常是成本：使用 Vercel 或 Netlify 这类按构建时长计费方案的团队，经常反馈切换到 Bun 后每月构建成本降低 20–30%，这也让基础设施成本这个角度，往往比单纯的原始性能更能推动迁移决策。

总结

Bun 1.2 已经足够稳定，能够为简单直接的 API 服务器、CLI 工具和 CI/CD 脚本带来立竿见影的收益。另一方面，依赖复杂原生模块或需要企业级 APM 的环境，继续使用 Node LTS 仍然更稳妥。对于新项目，可以选择 Bun；对于现有项目，建议采用分阶段迁移。