bun的基准测试结果令人印象深刻，其http服务器性能在框架性能榜单中名列前茅，这让我眼前一亮。npm包的安装速度也显著提升，甚至让我考虑放弃pnpm。
然而，在实际使用过程中，我发现了一些问题。 最初，我对Bun宣传中的一些说法持怀疑态度，但现在我更倾向于认同其部分观点。
我遇到的主要问题在于对运行时无关的包（例如Amazon S3和SQLite库）的支持不足。我认为Bun在开发者体验方面还有提升空间。 我使用Bun和VS Code的过程中，调试功能存在诸多问题：
- Bun不总是能正确识别断点，除非运行时存在端口监听器或某些函数处于“挂起”状态。
inspect-brk和inspect-wait也无效，即使使用了官方的Bun VS Code扩展和Volta.sh。 - 调试器的行为在启动和“运行文件”之间不稳定，尤其是在远程/隧道和本地开发环境之间切换时。
- 网络调试器也存在问题，尤其是在处理
await时，它可能会完全丢失某些等待中的Promise。 - 即使使用source map，JavaScript代码也无法正确映射到同一monorepo中的TypeScript文件。 我不得不手动杀死端口才能解决端口被占用问题，为此我创建了以下
tasks.json文件：
{
"version": "2.0.0",
"tasks": [
{
"label": "kill port",
"type": "shell",
"command": "lsof -ti:3000 | xargs kill -9",
"problemMatcher": []
}
]
}
Bun的测试运行器虽然功能强大，但与VS Code的测试资源管理器集成度不高，导致难以可视化和运行在VS Code中最后一次运行中失败的测试。虽然它具有CLI中的过滤器选项，但需要手动指定失败的测试，调试体验也不佳。此外，我还遇到了一些奇怪的断言错误，这可能与Bun处理monorepo的方式有关。 我不得不使用obj.constructor.toString() === className.toString()来替代instanceof操作来解决这个问题。
Bun在处理monorepo和多根工作区时也存在不足。构建和安装过程有时会与存储库中的包冲突，这在使用npm时从未遇到过。VS Code也不总是能正确识别Bun的启动配置。
Bun的构建过程虽然很快，但它接受了一些TypeScript编译器（tsc）不允许的代码，并且对tsconfig.json的遵守也不够严格。默认情况下，Bun会将所有外部模块打包到捆绑包中，外部和包标志的使用也比较混乱。
最终，我为项目中Bun的使用制定了以下策略：
- 库: 使用tsc进行编译，以提高速度并确保与CommonJS兼容。
- 调试: 使用Node.js和source map进行调试，以便在VS Code中正确调试TypeScript代码。
- 服务器/应用程序: 使用Bun，因为它在运行时更快、更高效。
- 包管理器和脚本: 使用Bun（虽然pnpm也是一个不错的选择，尤其是在减少磁盘空间占用方面）。
总而言之，Bun是一个很有潜力的工具，但它在开发者体验方面仍有改进空间，尤其是在调试、monorepo和多根工作区支持方面。 在选择使用Bun时，需要仔细权衡其优势和不足。
