常见问题

Bun 能用于生产吗？

能，但按边界采用。Bun 是 MIT 许可的开源项目（Zig 编写），大量服务已在生产运行。判断依据不是宣传，而是你自己的验收：按 生产工程基线 跑类型检查、测试、目标环境启动、压测与回滚演练。有保守要求的团队可以只先替换包管理与测试。

Bun 会替代 npm 吗？

bun install 是完整的包管理器，但两者可以共存过渡：迁移期保留原锁文件评审，切换获批后只留一个权威锁文件。详见 从 Node.js 迁移。

Bun 会做 TypeScript 类型检查吗？

不会。Bun 剥离类型后执行，不做静态检查。仓库里始终保留 tsc --noEmit 脚本并放进 CI，见 运行时。

Windows 支持如何？

支持 Windows 10 1809 及更新版本，官方有原生构建。个别 API 在 Windows 上有行为差异或尚未实现，涉及子进程、信号和文件系统路径时在 Windows 目标机上实测，见 5 分钟上手 的安装部分。

bun.lock 和 bun.lockb 是什么关系？

bun.lockb 是旧的二进制格式；1.2.0 起默认生成文本格式 bun.lock（可 diff、可评审）。新项目只会有 bun.lock；老项目升级后建议迁移并删除旧文件。背景见 版本特性矩阵。

现有 Node.js 项目必须一次全迁吗？

不需要，也不应该。推荐并行采用：先脚本，再包管理，再测试，最后才是生产运行时；每一步都有通过条件和回滚路径。完整阶段表见 从 Node.js 迁移。

.node 原生扩展能用吗？

Bun 实现了 Node-API，很多原生扩展可以直接工作，但不是全部。含有原生依赖的项目，先在目标 OS/CPU 上做最小加载与功能测试，再决定迁移范围；失败证据记录进 已知问题 或项目迁移文档。

用了 Bun，Next.js / Vite 项目的构建链要换吗？

不要主动换。框架的官方构建命令仍是事实源；Bun 可以承担包管理、脚本执行甚至 bun --bun 运行框架 CLI，但构建仍由框架自己的管线完成。判断表见 生态选型决策。

Bun 和 Deno 怎么选？

看权限模型、包生态和部署形态，不看微基准：需要默认沙箱选 Deno，想要 npm 兼容加单工具链选 Bun，重原生扩展和 LTS 选 Node。完整对照见 与 Node.js、Deno 对比。

某个 flag 或 API 在我的版本上没有？

先 bun --version，再查 版本特性矩阵 确认最低版本；行为对不上时按 常见报错对照 的排错顺序处理。

官方参考：Bun 官方文档、oven-sh/bun。