我最近把 Intlayer（一个 i18n 解决方案） ——一个由多个应用组成的 monorepo（Next.js、Vite、React、design-system 等）从 pnpm 迁移到了 Bun。
总结（TL;DR）：如果早知道，我可能不会这么做。
我以为只需要几个小时，结果花了大约 20 个小时。
我被 Bun 的 “一体化” 承诺和令人印象深刻的性能基准吸引。
我提示、我 cursor、我的包构建飞快，太棒了。
然后我提交（commit）……遇到了第一个问题。
Husky 崩了
原来你需要手动在 commit-msg 和 pre-commit 文件中添加 Bun 的路径。
没有任何官方文档提到这一点。
我不得不在 GitHub issue 里深挖才找到解决办法。
接下来是 GitHub Actions。
修改 → 推送 → 等待 → 检查 → 修复 → 重复 × 15 次。
我花了 3 个小时调试缓存问题。
终于，一切构建通过。是时候运行应用了……或者我以为是。
后端（Backend）
问题 1：
使用 express-rate-limit 导致所有请求都失败。
问题 2：
我的应用使用了 express-intlayer，它依赖 cls-hooked 来处理上下文变量。
而 Bun 不支持 cls-hooked。
解决方案： 用 Bun 构建，用 Node 运行。
网站（Website）
问题 1：
本地构建正常，但在使用官方 Bun 镜像的容器中构建时，会无限卡住、CPU 占满、服务器直接崩溃。
我不得不回退。
我找到一个 2023 年的 GitHub issue，建议的解决方案是：使用 Node 镜像并手动安装 Bun。
问题 2：
我的 design system 组件开始报 “module not found” 错误。
Bun 仍然在包路径解析上存在问题。
我不得不替换掉所有 createRequire 的调用（为了解决 CJS/ESM 兼容问题），并将 require 函数手动传递给每个需要它的函数。
其他错误就不一一赘述了。
经过很多小时的折腾，我终于让一切都跑起来了。
那么 CI 性能提升如何呢？
| 项目 | 迁移前 | 迁移后 |
|---|---|---|
| 后端 CI/CD | 5 分钟 | 4 分 30 秒 |
| 服务器 MCP | 4 分钟 | 3 分钟 |
| Storybook | 8 分钟 | 6 分钟 |
| Next.js 应用 | 13 分钟 | 11 分钟 |
在运行时方面，我的 Express 和 Next.js 应用仍然在 Node 上运行。
结论
如果你在想 “现在是迁移到 Bun 的时候了吗？”
我的回答是：
它可以用，但对于复杂场景来说还不够成熟。
尽管如此，我依然非常看好 Bun 的潜力，也很好奇它未来会如何发展。
你在迁移过程中有没有遇到类似的问题？
