前段时间，不是看了 Cloude Code 源码嘛，里边用到 Bun。之前也听说过，但一直没有尝试过。还听到有同事自己也在用，所以就勾起我想好好熟悉一下 Bun。

于是，我给自己定了个小目标：把 Bun 从“听说很快”练到“我知道它哪里快、哪里会翻车、该怎么用”。

然后我就做了一个 10 章的小项目，从 hello world 一路打到 runtime、http、sqlite、测试、websocket 和最终小项目。

项目地址先放这里：
👉 bun-learning-journey

这篇文章我想聊三件事：

1. Bun 到底是什么，我为什么愿意花时间系统练一遍
2. Bun 为啥会比 Node / Deno 给人的“体感更快”
3. Bun 现在市场使用率和成熟度到底怎么样，能不能上生产

我为什么做这个项目

我最开始对 Bun 的印象就一句话：“快，但是不稳”。

这种印象很容易停留在口水战里，所以我干脆用项目把它拆开。

这个仓库我按学习路径做成了 10 章：

• 01-hello：最小启动
• 02-runtime：顶层 await、Bun.env、Bun.sleep
• 03-package-manager：bun install、脚本执行
• 04-http-server：Bun.serve + REST
• 05-file-io：Bun.file / Bun.write
• 06-sqlite：bun:sqlite 做 CRUD 和分页/JOIN
• 07-testing：bun:test + mock + coverage
• 08-bundler：Bun.build + splitting + define
• 09-websocket：实时聊天（房间、私聊、输入中、SQLite 持久化）
• 10-final-project：收口做完整小应用

做完之后我的结论是：
Bun 不是“银弹”，但它确实是我近两年在 JS 侧感受到“开发链路最短”的工具。

Bun 到底快在哪

很多文章只说“Bun 很快”，但不说机制。我按我这次实操的体感，总结成 5 点：

1）启动快：运行时和转译链路很短

Bun 基于 JavaScriptCore，启动延迟很低；官方文档也一直强调它的启动速度优势。

我在本地最直观的感受是：跑小脚本、跑工具脚本、跑测试时，“按下回车到看到输出”的时间明显短。
（官方文档里也给了 bun vs node 的启动对比）Bun Runtime 文档

2）少进程、少拼装：一个二进制干很多事

Node 生态常见链路是：Node + npm/pnpm + tsx/ts-node + jest/vitest + bundler。

Bun 把 runtime / package manager / test runner / bundler 集成在一起，少了很多工具间切换和冷启动。

这个在中小项目里，体感加速非常明显。

3）内置能力多，减少第三方依赖

我在练习里大量用到这些内置能力：

• Bun.serve
• Bun.file / Bun.write
• bun:sqlite
• bun:test
• Bun.build

这意味着我不用先装一堆包再拼接脚手架，项目从“搭环境”到“写业务”的时间被压缩了。

4）包管理很激进，安装速度很顶

很多同学第一次感知 Bun，都是 bun install。

它在缓存和链接策略上做得比较激进，安装速度确实常常比 npm 快一截。
（具体倍率和场景差异很大，别迷信单次 benchmark。）

5）Web 场景优化明显（HTTP / WebSocket）

我在第 4 章和第 9 章写 HTTP + WS 时，性能和 API 设计都很顺手。

尤其 Bun.serve + pub/sub 的 WebSocket 路线，代码量很少就能做出完整聊天室。

市场使用率：现在到底在哪个阶段

我尽量不“吹”，就说我看到的事实和判断。

先说结论

• Node 仍然是绝对主流，这一点没有争议。
• Bun 在快速增长，尤其在新项目、工具链、CLI、边缘服务里越来越常见。
• Bun 更像“增量替换”而不是“一夜替代”：先从 bun install、bun test、工具脚本开始替换，再逐步评估 runtime 迁移。

公开信号（截至我写文时）

• npm 上 bun 包周下载量在百万级（我看到的是约 138 万/周）npm 包页面
• GitHub 仓库 star 大约 89k+（增长一直比较快）GitHub 仓库

我自己的理解：
这两个数字说明 Bun 已经过了“玩具期”，但距离 Node 那种“企业默认项”还有距离。
所以我会把它定义为：“可生产，但要分场景上线”。

我建议怎么用 Bun（实战向）

如果你在团队里推动，我建议按这个顺序：

1. 低风险切入：先用 bun install、bun test、脚本执行
2. 服务侧试点：挑一个中小 API 服务用 Bun.serve 跑
3. 数据库场景验证：试 bun:sqlite 或你现有驱动兼容性
4. CI 加回归：覆盖 Linux / macOS，补关键链路测试
5. 最后再谈全量迁移：尤其是复杂 Node 历史项目，不要一刀切

我这个项目能帮你什么

如果你想系统练 Bun，我这个仓库就是按“从入门到可落地”设计的：

👉 github.com/RainyNight9…

你可以直接这样用：

• 从 01 到 10 按顺序跑
• 每章先看 README，再看 index.ts
• 我把很多练习都补成了可运行实现（不是只给题目）

如果你已经会 Node，这个项目大概率能帮你在 1~2 天内建立 Bun 的完整心智模型。

最后的态度：我会继续用吗？

会，而且会继续扩大使用范围。

但我的策略不是“全换”，而是有节奏地换：

• 新项目优先考虑 Bun
• 老项目我可能就动了，稳定第一，如有真实的需要场景，再切换
• 性能敏感、工具链痛点明显的地方优先上

一句话总结：
Bun 不只是“快”，更值钱的是它把 JavaScript 工具链做短了。
而“链路变短”，通常就是工程效率真正提升的开始。