1. 为什么我把重心从 Node 切到了 Bun先说结论Bun 不是又一个跑得更快的 Node它是一整套重新设计过的 JavaScript 运行时和工具链。我最初对它的态度是观望因为这类下一代运行时的宣发见过太多次了但真正在几个中等体量的项目里跑过之后我发现它解决的问题恰好都是我在 Node Webpack ts-node 这条链路上常年忍受的痛点。最直接的体会是速度。一台 2020 年左右的开发机上Bun 安装依赖的速度比 npm 快出一个数量级冷启动跑一个 HTTP 服务从按下回车到监听端口体感基本是瞬间完成。这些不是玄学是它底层架构决定的后面我会详细拆解。这篇文章的目标读者是两类人一类是每天跟 Node、npm、Webpack 打交道的应用开发者想知道换工具链到底能省多少事另一类是维护 CLI 工具、内部服务或者想给团队做基建的同学需要评估 Bun 能不能作为新项目的底座。我会把运行时、包管理器、打包器、测试器这几个模块拆开讲最后给出一套我实际用下来的迁移建议和踩坑清单。2. Bun 到底是另一个 Node还是全新的东西2.1 它解决了 Node 生态里哪些积压已久的问题Node 本身是个非常成功的运行时但它的成功也带来了历史包袱。模块系统从 CommonJS 到 ESM 的过渡磨了快十年到现在还有很多库在双格式之间做兼容层npm install 在大项目上动辄几分钟node_modules 的体积动辄上 GBts-node 和 tsx 这类工具本质上是在运行时外面再包一层编译逻辑启动慢不说还常常和原生 ESM 行为产生偏差。Bun 的思路是推倒重来但又不是完全无视生态。它用 Zig 写了 JavaScriptCore 绑定和原生工具链把运行时、包管理器、打包器、测试器、转译器全部揉进一个二进制文件里。这意味着你装一个 bun相当于同时拥有了 node、npm、webpack、jest、babel 的替代品。听起来很激进但实际用下来这种全家桶模式在工程效率上的提升非常明显。它的转译器默认支持 TS、JSX所以在 Bun 里面你可以直接跑 .ts 文件不需要额外的编译步骤。这个能力底层是内置的打包器在起作用它把 TypeScript 的类型信息剥离掉同时将 ESM 转成一种内部模块格式来执行。这个过程发生在运行时之前的加载阶段所以实际执行效率和原生模块并没有数量级的差别。2.2 性能数据背后藏着什么可能你已经看过一些 benchmark比如 Bun 的 HTTP 服务器吞吐量比 Node 的默认实现高不少。真实项目里这个数字会缩水但方向是一致的。原因主要有三个第一Bun 用了 JavaScriptCore 作为 JS 引擎而 Node 用的是 V8。两者在 JIT 编译策略和内存管理上有差异JavaScriptCore 在启动速度和冷启动场景下表现更好。第二网络层是基于 Zig 写的io_uring 这样的异步 I/O 机制在支持的平台上被充分利用。简单类比一下Node 的事件循环是单线程配合线程池来做文件 I/O 和 DNS 查询而 Bun 在某些 I/O 路径上可以做得更异步化减少线程切换的开销。第三Bun 的原生代码和 JS 运行时共享同一个内存空间的问题被人专门优化过跨语言边界的调用比 Node 的 C 绑定要轻快尤其在频繁小对象交互时优势明显。需要提醒的是不要被性能天花板迷住。我自己的压测里Bun 做纯计算密集型任务时优势并不夸张它最强的是被 Node 生态拖累的那些场景——依赖安装、启动速度、开发时热更新、TS 编译。这些都是开发效率和 CI 耗时的大头恰恰是最容易被日常感知到的部分。3. 跑一个真实项目需要动哪些地方3.1 创建一个 Bun 项目的最小步骤如果你已经安装了 BunmacOS 和 Linux 一行脚本Windows 也有安装包可以先从最基础的初始化开始mkdir bun-demo cd bun-demo bun init -y它会生成一个 package.json 和一个入口文件。这个 package.json 和我们熟悉的结构几乎一样但你还多了一个 bun.lockb这是一个二进制格式的锁文件用来锁定依赖版本。注意它和 package-lock.json 不兼容所以在 Bun 项目里别混用 npm否则容易踩锁文件冲突的坑。接下来安装依赖就简单了bun add express对比 npm install 的耗时同样网络条件下这个命令基本在一秒左右完成。它的并发安装策略是同时拉取所有需要的包然后做全局缓存第二次安装甚至可能快到察觉不到。跑 TypeScript 文件也不需要额外配置bun run index.ts这一条命令同时完成了转译和执行。如果你之前用过 ts-node会明显感觉到差异——Bun 的启动几乎没有可感知的等待。3.2 我需要改代码写法吗这是大部分人迁移前最关心的问题。我给你一个直接的结论大部分项目几乎不用改代码。Bun 做得很聪明的一点是默认兼容 CommonJS 和 ESM并且和 Node 的全局对象基本对齐。process、Buffer、__dirname 这些 Node 风格的 API 在 Bun 里都可用很多原本为 Node 写的模块直接 require 也能跑。不过需要留意几个和 Node 行为不一致的地方一是 Node 的某些 API 在 Bun 里只是部分实现比如 worker_threads 的功能还不完全一致重 CPU 并发场景要验证过再用。二是一些特定模块比如 node:fsBun 提供了原生实现但在文件监听等行为细节上和 Node 有差异。开发时用的文件监听、崩溃日志这类场景建议在切换后多跑几轮测试。三是 npm 包如果包含原生编译节点.node 文件Bun 和 Node 对原生模块的安装方式有区别。Bun 有自己的原生模块支持机制遇到这种包最好先看看它的安装脚本是否兼容否则可能导致步骤构建失败。为了让迁移更平滑我在项目里加了这样几条配置{ type: module }这个字段会让 .js 文件默认当成 ESM 处理如果你的项目已经全面使用 import/export这个设置能减少很多潜在歧义。3.3 bun run 到底做了什么bun run 不是简单的命令转发。它会把 package.json 里的 scripts 解析后使用内置的 Shell 子集去执行。这意味着大多数 shell 语法在 scripts 里可以直接用比如scripts: { build: bun run lint bun build src/index.ts --outdirdist }不需要额外安装 cross-env 之类的包Bun 在设置环境变量时用 Shell 子集也能处理得很好。一个小技巧是bun run 支持--bun前缀来强制用 Bun 运行时替代 Node 去执行某些 node 脚本这对一些内部小工具非常有用。甚至你可以在 scripts 里直接写dev: bun --bun next dev这样就能让一些原本只能用 Node 启动的框架跑在 Bun 运行时之上。不过这类套壳方案在一些深度依赖 Node 特定行为的框架上可能翻车我建议先拿一个小页面试验别一上来把整个生产环境切过去。4. Bun 的包管理器凭什么比 npm 快4.1 安装策略的本质差异npm 和 yarn classic 之所以慢根本原因是它们需要在每个包安装的时候执行对应的生命周期脚本preinstall、postinstall 等而且很多包的安装脚本会下载二进制、编译源码这些步骤几乎没法并发处理。Bun 的策略是尽量不给项目级依赖执行任意脚本它把每个包的元数据从注册表拉下来之后用统一的、并行的方式去做硬链接和缓存处理。具体到安装过程Bun 会将依赖的目录结构提前计算好然后以小并发的方式快速落盘。npm 需要逐包递归解析依赖树Bun 会在解析阶段就利用二进制格式的清单减少 I/O 开销。所以你在一个已经有缓存的机器上跑 bun install往往不到一秒钟就显示所有依赖就绪。但是要注意Bun 对依赖脚本的处理和 npm 并不是完全一致的。很多包依赖 postinstall 来做一些初始化工作比如 esbuild 会下载平台对应的二进制。Bun 对这些信任名单里的包会照常执行脚本但对于其他包它默认是忽略脚本的。这在安全性上是好事因为减少了供应链脚本攻击面但遇到个别行为怪异的包可能装完之后缺东西。所以我的建议是CI 里迁移到 bun install 之后一定要跑一个完整的测试和构建流程确认每个包的基础行为都正常。4.2 和 pnpm 的硬链接方案对比pnpm 也很聪明它用全局内容寻址存储 项目内硬链接的方式来节省磁盘空间。Bun 的全局缓存方案思路类似但实现层面完全不同。Bun 的缓存目录在 macOS 上是 ~/.bun/install/cache它保存的是解压后的包。安装时它通过一种内容寻址的方式判断是否已经有现成的文件有的话直接复用极大减少了重复下载和网络 I/O。从开发者体验来说我个人体感 Bun 的一个优势是它对安装后立即可用的建模更直观——不需要像 pnpm 那样依赖符号链接解析带来的复杂边界情况。但如果你有非常复杂的 monorepo 依赖图谱pnpm 的 workspace 支持更成熟。Bun 的 workspace 也在进步但在一些精细场景比如不同包之间 peerDependencies 的自动解析上会碰到需要手动处理的 case。我通常会这样选新项目用 Bun 作为默认工具链老项目如果还在 pnpm 上跑得很稳就不必强行迁移性价比不高。4.3 锁文件策略与团队协作bun.lockb 是二进制格式这给 PR 审查带来一点不便因为没法直接 diff。Bun 也支持生成文本格式的锁文件版本你可以通过配置让锁文件以可读格式输出这样在 code review 时要看依赖变化就直观多了。团队协作时建议统一 Bun 版本因为锁文件格式会随版本演进。可以加一个配置文件固定引擎范围engines: { bun: 1.0.0 }然后配合 CI 检查 bun --version避免有人用不同版本生成不同的锁文件。5. 内置打包器Webpack 时代的终结者还是补充5.1 Bun build 解决的问题Webpack 这些年被吐槽最多的是配置复杂和构建慢。Bun 内置的打包器直接把这两件事做了减法。一个典型场景是构建一个浏览器可运行的 bundlebun build ./src/index.tsx --outdir./dist --minify这个命令会做依赖解析、Tree Shaking、压缩并且自动处理 JSX 和 TypeScript。不需要 webpack.config.js 那几十行配置也不需要额外装 babel-loader、ts-loader。打包结果还支持自定义外部模块、注入环境变量bun build ./src/index.tsx --outdir./dist --define process.env.NODE_ENVproduction这里的 --define 在打包时就把代码里的全局标识符替换成字面量作用类似 Webpack 的 DefinePlugin但写法更简单。5.2 它和 esbuild 的异同esbuild 已经是很多项目替换 Webpack 的首选Bun 的打包器在架构上和 esbuild 有相似之处——都是 Go/Zig 写的原生实现。但 Bun 更深一层它连运行时、打包器、转译器都共用一个代码基础因此在处理打包后的代码能否在 Bun 运行时里跑这个问题上能做到无缝衔接。esbuild 在某些极端分包code splitting场景上表现很好Bun 的分包策略目前相对简单如果一个项目对分包粒度有非常细致的要求可能还得多配一个专门的打包器来输出最终的产物。不过日常应用层的 bundleBun 已经完全够用。我自己在测试一个内部工具时用 Bun 替换掉了原来的 Webpack 构建构建时间从 40 秒降到 3 秒左右。对于 HMR 开发服务器变化更明显通常改动一个文件Webpack Dev Server 可能需要 1 到 3 秒完成重新编译Bun 几乎在保存的一瞬间就能刷新页面。5.3 用 Bun 构建 SSR 的同构代码如果你做 SSR 或者同构应用Bun 的打包器有个方便之处可以直接声明 target 为 bun让输出专门适配运行时环境bun build ./src/server.tsx --targetbun --outdir./dist-server这样构建产物可以避免一些浏览器环境特有的 polyfill 注入产物体积更小运行也更直接。在做一个模拟全栈项目时我把客户端 bundle 和服务端入口全部交给 Bun 处理整个过程不装任何额外 loader代码量少了很多。当然生产上如果要接入 CDN、服务端部署到特定云平台仍然需要考虑产物格式跟平台是否兼容的问题。6. 测试与开发体验被低估的两个模块6.1 Bun test 的替代者身份Jest 在大型项目里的痛点主要是两个配置麻烦、跑得慢。Bun 内置了一个和 Jest API 高度兼容的测试运行器你几乎可以把 test 和 expect 直接替换过来。示例测试文件import { describe, test, expect } from bun:test; describe(math, () { test(add, () { expect(1 1).toBe(2); }); });对这个文件执行 bun test它会自动发现 .test.ts 文件并执行不需要配置 testMatch 那种正则。它同时也支持 mock 和 snapshot基本的单测场景都覆盖到了。最明显的差异在于执行速度。Jest 跑一千来个测试用例往往需要十几秒甚至更多Bun test 在同样机器上通常能做到一两秒。原因是它利用运行时内置的转译能力省去了 Jest 里 Babel 编译这一步并且测试并发执行更激进。但注意并不是所有 Jest 生态的库都能无缝替代。比如 jest-dom 这类扩展 matcher 的库需要看看是否存在对应的 Bun 兼容版本。在我测试过的几个项目中把 Jest 换成 Bun test 之后个别测试用了 setTimeout 模拟异步等待的方式Bun 的时钟机制和 Jest 不同这类测试要改造成用真实的 Promise 微任务否则偶发超时。6.2 内置热重载和开发服务器Bun 支持--hot参数让开发服务器在检测到文件变化后自动重载模块。bun --hot server.ts它和 nodemon 那种重启进程完全不同这个 hot 模式是在当前进程内做模块级替换速度非常快。不过变化的是模块引用图的时候有些状态不会保留和浏览器的 HMR 边界类似。如果你的服务是无状态的那这个模式跑起来非常顺手如果服务里维护了内存缓存建议在模块级别做好清理钩子。我实际使用中的一个心得是在开发阶段用 bun --hot Bun 内置的 SQLite 支持配合做一个本地 mock 服务非常舒服不需要嫂子什么额外配置改动代码几乎即时生效反馈循环快了非常多。7. 从 Node 迁移到 Bun 的完整避坑清单7.1 按迁移步骤梳理的检查点节点是学名步奏上建议按下面的顺序走每一步都验证之后再进入下一步。第一步把开发依赖的安装切换到 bun install跑通所有测试。如果测试覆盖率够这里基本上能暴露 90% 的兼容性问题。第二步把测试运行器从 Jest 或 Vitest 切换到 bun test注意清理 test 文件里的 Jest 特有 API。有的项目用了 jest.mock 的自动 mock 行为Bun 里 mock 的实现略有差异需要做适配。第三步把开发服务器切到 bun run dev 或 bun --hot。这个阶段重点观察模块热更新是否正常以及内存占用是否可控。第四步尝试用 bun build 替换打包流程。这一步如果项目用了复杂的 Webpack Loader 或 Plugin就不能简单替换了。遇到这种情况建议先把 Bun 只用于构建部分页面或做环境变量注入逐步验证。第五步生产环境的运行时切换。确认你的部署平台支持 Bun 运行时或者干脆把 Bun 编译成单文件可执行程序再部署。7.2 我踩过的一个实际坑模块解析顺序有次我在一个项目里同时安装了 local package 和 npm 包而两者的名字相似。Bun 的模块解析顺序和 Node 大体一致但在某些边界 case 上不完全一致导致我开发时跑得好好的一执行 bun build 就因为解析到不同版本的依赖而打爆了类型检查。排查之后发现是它有缓存了 node_modules 下的临时文件但我手动改了某个包的版本。这个教训是Bun 的缓存很激进如果遇到诡异的我明明改了代码但行为不变的情况先考虑清缓存bun pm cache rm然后再重新安装。这类问题不是 Bun 独有但因为它太快了反而更容易让人忽略缓存的存在。另外一个值得注意的点是Bun 对node:模块的一些 polyfill 做了简化处理。比如 node:child_process 在某些平台上的行为表现没有 Node 那么精细。如果你依赖这些东西去做进程管理生产环境要提前做压测别等到流量上来才发现问题。7.3 团队与 CI 层面的适配建议CI 里有几个容易被忽略的地方Docker 镜像需要安装 Bun尽量使用官方提供的多阶段构建基础镜像别在 Linux 容器里手动下载脚本既慢又容易引入不可控因素。如果 CI 里同时用了 npm 和 bun确保它们各自操作独立的锁文件目录避免 node_modules 里出现混装的状态。在构建产物上传环节Bun build 生成的产物大小通常比 Webpack 小但资源文件的哈希命名规则不同CDN 缓存策略需要对应调整。我记得有一次线上样式文件加载失败就是因为 Webpack 和 Bun 对 css 文件内部引用的url()路径处理不同导致构建产物里的相对路径在 CDN 上失效。这类问题不应该靠临时补路径解决而是要在打包阶段统一配置 base 路径和资源前缀。8. 什么时候不应该用 Bun这个问题比什么时候用 Bun更值得聊。第一如果你的核心依赖是某些只针对 Node 运行时深度优化的原生模块比如专门使用 V8 内部 API 的Bun 的 JavaScriptCore 可能不兼容。这类依赖常见的场景是一些深度性能监控 agent、特定图形处理库等。迁移前必须逐个验证。第二如果你重度依赖 Node 的某些实验性特性或者 Node 独有的 API 正在快速增长Bun 的跟进速度未必赶得上。比如 Node 最近几个版本在 Web Streams API 方面的实现很完善而 Bun 对这些的支持成熟度还在追赶。第三如果你在维护一个老旧的、使用了大量 Gulp 任务和 Webpack 插件的构建链直接迁移成本会很高。这种情况下我建议保留原有构建链只在开发服务器环节引入 Bun 提速边界收益比全量迁移高很多。还有一点容易忽略要不要为了快去追逐一个生态还没完全成熟的新工具。如果你的团队没有时间处理兼容性 bug强上 Bun 反而可能在周报里多出一条排查 Bun 导致的生产问题。这个风险要和收益一起摆到台面上评估。9. 实际性能数据参考与配置示例9.1 一个模拟项目的对比我拿一个内部模拟项目做了对比项目情况如下100 个左右 npm 依赖40 个 TypeScript 源码文件包含 Express 服务的启动逻辑和若干单元测试。操作npm Node JestBun首次安装依赖62 秒8 秒启动 HTTP 服务到 ready1.8 秒0.4 秒跑 200 个测试用例21 秒2.6 秒生产构建41 秒4.1 秒开发热更新响应2 到 4 秒0.3 秒数据因机器和网络环境而异但倍数级别的差距是一致的。我用的开发机配置很一般Intel i5 16G跑出来的结果已经很能说明问题了。其中让人最惊讶的不是某项单独的数据而是每一项都有提升这种所有环节一起变快的体验才是换工具链能带来最大价值的地方。单独追某个指标可以靠工具优化但全链路一起提速说明架构层面的设计确实起到了作用。9.2 生产环境的单文件部署Bun 支持把整个应用编译成一个可执行文件这在部署小型工具服务时非常有用bun build ./server.ts --compile --outfile my-server生成的二进制文件自带运行环境不需要目标机器再安装 Bun 或者 Node。如果服务器是 Alpine Linux这种方案还能省去一堆系统依赖的安装步骤CI 镜像能小非常多。我在一个内部数据面板项目里用了这个方式部署包从展开后的几百 MB Node 模块变成一个 60 MB 左右的单文件启动时间也快了一大截。唯一的限制是这个编译产物必须运行在兼容的系统架构上做分发时要区分 x64 和 arm64和 C 程序的交叉编译逻辑类似。10. 我的一些实际心得以及下一步想做的事用 Bun 半年多最真实的感受是工具链终于不再是瓶颈了。以前改代码等打包、等热更新、等测试跑完那种等待感会打断思路。现在基本是保存即反馈开发体验的提升很难逆转回不到原来的慢节奏了。我下一步想重点验证的是 Bun 在服务器端事件驱动场景下并发模型的稳定性尤其是跑满 CPU 和大量 WebSocket 连接时的表现。现有数据看起来不错但生产级的稳定性需要更长时间的观察。对于准备尝试的读者我的建议是挑一个内部低风险项目先跑几周真实负载比任何 benchmark 都有说服力。最后分享一个小技巧在 package.json 里配置trustedDependencies字段把那些确实需要执行安装脚本的包加进去这样既能享受 Bun 安装的高效又能避免某些包因为跳过脚本而功能缺失。具体写法是trustedDependencies: [sharp, esbuild]这算是我在实际项目里总结出的最实用的一行配置了。工具链的更替从来不是非黑即白Bun 目前给我的感觉是——方向对底子硬剩下的只是时间问题。