跳到主要内容

Bun 专题总览

Bun 最容易让人误判的地方，是它看起来像一个工具名，实际却横跨了好几层：

  • package manager
  • runtime
  • test runner
  • bundler
  • workspace 工具
  • Docker / CI 里的工程入口

所以如果只在 包管理 里看它，会漏掉 runtime 和服务端能力；只在 Node 与服务端 里看它，又会漏掉 bun install、bunx、workspaces 这些对前端工程更常见的切入点。

这就是为什么把 Bun 单独拉成一个专题目录会更顺。

建议阅读顺序​

  1. Bun 的定位与主线能力
  2. 包管理、bunx 与脚本执行
  3. 运行时与服务端能力
  4. 测试能力与 bun test
  5. Bundler 与构建能力
  6. Workspaces、Docker 与 CI
  7. 兼容性、迁移与采用策略
  8. bunfig.toml 配置文件
  9. Bun Shell、脚本与进程能力
  10. Bun 与 Node、pnpm、Vite、Vitest 的对照

先用一句话看 Bun​

如果要把 Bun 说得更准确一点，它不是“某一个点更快”的工具，而是一条试图把 JavaScript / TypeScript 开发链路收成单一入口的路线。

最适合先从哪里切进去​

只想先试一小步​

先看：

  • bun install
  • bun run
  • bunx

这类切法对现有项目最友好。

想认真看 runtime​

先看：

  • bun run index.ts
  • Bun.serve
  • bun test

这类切法更像在重新判断一套运行时和服务端工具链。

想在团队项目里落地​

先看：

  • lockfile
  • workspaces
  • Docker
  • CI
  • 兼容边界

这几层没看清之前，不适合贸然把生产主线全部切过去。

Bun 和现有主线的关系​

Bun 很少是“一夜之间全仓替换”的工具。更常见的采用顺序通常是：

  1. 先当包管理器
  2. 再当脚本执行器
  3. 再看 test runner 和 bundler
  4. 最后才决定 runtime 是否接管服务

这样推进会稳很多。