Bun快3倍？这话只对了一半

前几天刷掘金，看到一篇帖子问”Bun能上生产吗”，底下评论区直接炸了——有人说”快到起飞，回不去Node了”，有人说”用了一周，bug多到想砸电脑”。

我在生产环境跑了3个月Bun。我的结论是：他们说的都对。关键看你拿它干什么。

“Bun比Node快”这句话，只说对了一半

很多人听到”Bun比Node快3倍”就热血上头，恨不得连夜把所有项目迁过去。

冷静一下。

Bun的”快”是真的，但它快在特定场景——启动速度、包安装、简单HTTP请求处理。你写个脚本跑个任务，那种丝滑感确实让人上瘾。

但生产环境不是跑脚本。生产环境是半夜三点你的oncall电话响了，你睡眼惺忪打开电脑，发现内存涨到8个G还在往上飙。

这就是我第一个月遇到的事。

三个月，三个坑

第一个坑：Stream内存泄漏。

我们有个服务做文件中转——接收上游的大文件，边收边转发给下游。在Node里跑了两年，稳得像老狗。换到Bun之后，小文件没问题，一旦文件超过500MB，内存就开始不对劲。

排查了两天，定位到Bun的ReadableStream实现有问题——背压（backpressure）机制不完善，数据进来的速度比出去的快，全堆在内存里。Node的Stream经过十几年打磨，这种边界情况早就处理得明明白白。Bun在这块，说实话，还嫩。

第二个坑：那1%的npm兼容性。

Bun号称npm兼容性99%。听起来很高对吧？

但当那不兼容的1%恰好是你项目里的核心依赖时，99%和0%没有区别。

我们用了一个基于node-gyp编译的加密库，Bun装是能装上，运行时偶发segfault。你没看错——段错误，进程直接挂。这种问题在Node生态里几乎见不到，因为大家都在那个稳定的V8引擎上跑。Bun用的是JavaScriptCore，某些native addon的兼容性还没完全打通。

第三个坑：生态工具链的坑。

用Node的时候，pm2、nodemon、各种APM工具、各种中间件，随便拿来就能用。换到Bun——pm2的cluster模式不支持，部分Express中间件行为不一致，APM的agent需要找替代方案。

这些不是Bun的bug，而是整个生态还没跟上。你不是在跟一个运行时打交道，你是在跟整个工具链打交道。

但是——Bun真的很快

说了这么多坑，话得说回来：Bun在它擅长的领域，那种快，是会让你对Node产生”回不去了”错觉的那种快。

我做了个简单的HTTP服务压测：一个返回JSON的接口，没有复杂中间件，没有数据库调用。结果Bun的QPS是Node的2.5倍，延迟低了60%。这不是官方Marketing数据，是我自己用wrk跑出来的。跑完我沉默了三秒，然后默默把我的CLI工具全切了过去。

启动速度更夸张。一个中等规模的项目，Node冷启动要3秒多，Bun只要400毫秒。写CLI工具时这个差距是致命的——用户敲个命令等3秒，他以为卡了；等0.4秒，他以为是本地程序。

包安装速度也离谱。bun install比npm install快5-10倍，比pnpm install也快2-3倍。同事第一次看我装依赖，以为我缓存作弊了。在CI流水线里，光这一项每天就能省好几个小时的机器时间。

Bun vs Node.js 实测数据对比

新车还是老车？

我喜欢用一个比方来解释Bun和Node的关系。

Bun像一辆刚出厂的性能跑车——加速快、操控好、内饰新潮。但4S店只有三家，配件要等进口，修车师傅拿到你这车型还得翻手册。

Node像一辆开了十年的丰田卡罗拉——不快，油耗一般，但什么路都能跑。路边随便一个修车铺都能修，配件满大街都是，你闭着眼开都不会出问题。

选哪个，取决于你是在赛道还是在送货。

赛道上，性能就是一切，跑车碾压。送货路上，你要的是”今天也能正常送到”，卡罗拉赢麻了。

场景推荐：该用Bun的地方和不该用的地方

踩了三个月坑之后，我总结了一个矩阵：

闭眼冲的场景：

  • CLI工具和脚本——这是Bun的主场。启动快、执行快、TypeScript原生支持，写完直接跑，不用编译。用过就回不去了，真的。
  • 内部工具和原型验证——不上生产、不怕挂、追求开发速度，Bun完美。老板催你出Demo的时候，Bun能救命。

可以用，但先写好遗书（回滚方案）的场景：

  • 简单的API服务（CRUD为主）——性能收益明显，但要配好监控和告警。内存、GC、连接数，盯紧了。出问题十分钟内能切回Node的方案也得准备好。

拜托先别用的场景：

  • SSR和复杂中间件链——Stream那些坑还在。你不想在用户访问高峰期看到502，然后对着Bun的GitHub Issues翻了一夜。
  • 重度依赖native addon的项目——segfault这种东西，遇一次就够你喝一壶的。
  • 已经稳定跑着的大型Node项目——你的项目在Node上跑得好好的，何苦呢。迁移成本远大于性能收益。

Bun 生产可用度场景推荐矩阵

像对待新同事一样对待Bun

回到开头那个掘金帖子的问题：Bun能上生产吗？

能。但请像对待一个能力很强、经验不足的新同事一样对待它。

这个新同事代码写得贼快，算法能力一流，但他不知道线上发布要先灰度，不知道日志要打到什么粒度，不知道凌晨三点数据库连接池满了该怎么处理。

你会把核心业务全交给他吗？不会。但你会不会让他先负责一些独立的、影响范围可控的模块？当然会。

Bun也是一样。让它先做CLI工具、跑跑脚本、搞搞内部系统。等它的Stream修好了，生态跟上了，社区的坑踩得差不多了——那时候再让它扛主力服务。

像对待新同事一样对待Bun

三个月前那个在掘金底下吵架的帖子，现在我可以给一个不吵架的回答了：

别问”Bun能不能上生产”，问”你的这个场景，Bun准备好了没有”。

答案藏在你凌晨三点有没有被oncall叫醒里。