Bun 工具链实测：秒删依赖与一体化 JavaScript 开发体验

这次我们来看一个在前端圈热度非常高的 JavaScript 工具链Bun。标题演示里的“Bun 1.4 用约 1.4 秒删除 15 个依赖”其实就是把 Bun 的包管理器能力放在一个极端场景下做了直观展示。如果大家还在 npm、yarn、pnpm 之间反复切换对 Bun 的感受可能还停留在“它启动很快”这个阶段那这次可以换个视角依赖安装、依赖删除、脚本执行、TypeScript 直跑这些东西能不能在一个工具里全部解决而且速度有肉眼可见的差异。Bun 不是一个新的“包管理替代品”那么简单。它是一整套 JavaScript/TypeScript 工具链默认包管理器、运行时、打包器、测试运行器全部内置。也就是说装完 Bun 之后你可以用它跑bun install装依赖用bun run跑脚本用bun test跑单测用bun build打包甚至直接写一个后端 HTTP 服务。本文会把 Bun 的定位、安装过程、依赖管理实测思路、运行时能力、常见问题和使用建议完整过一遍重点是让你看完之后能自己搭一个测试项目验证“秒删依赖”到底是怎么做到的。1. 核心能力速览先看 Bun 项目本身的能力项方便判断它适合什么场景。能力项说明项目类型JavaScript / TypeScript 运行时 包管理器 打包器 测试运行器开源情况MIT 协议开源核心引擎JavaScriptCore非 V8包管理器兼容 npm 生态bun install可替换npm install运行时能力直接运行.ts、.jsx、.tsx无需额外转译支持平台macOS、Linux、Windows 原生支持Windows 推荐配合 WSL 使用启动方式命令行工具安装后直接bun命令API 能力内置Bun.serve()、Bun.sql()、Bun.file()等 API批量任务支持bun run并行执行脚本适合 CI 和本地批量任务一键启动官方提供安装脚本非图形化一键包显存/内存占用无 GPU 依赖内存占用与 Node.js 接近需按实际项目测试从这张表能看出Bun 的定位是“一体化工具链”不是只解决依赖安装速度。如果你在写前端项目可以用它替代 npm/yarn/pnpm如果你在写 Node 后端可以直接把 Bun 当运行时如果你要跑 CI 脚本、写一次性工具脚本它也比传统 Node 环境更方便。2. 为什么“秒删依赖”值得关注先聊依赖管理本身。前端工程化里最容易被拖慢的环节往往不是业务代码而是依赖树的安装和变更。社区里大量高频问题都和依赖有关vue 项目安装依赖失败、Maven 依赖包下载不下来、Python 项目缺 requirements.txt、Spring 项目循环依赖、chi 上的青龙面板依赖管理报错、Java 后端启动时 Maven 刷新依赖卡住……这些问题虽然技术栈不同但根因类似依赖解析过程复杂、网络环境不稳定、本地缓存策略低效、工具本身串行处理。Bun 解决的是 JavaScript 生态里的这一层问题。它的包管理器在设计上做了几件关键事用全局缓存加硬链接项目之间不重复下载同一份包。依赖解析并发执行不逐个等待。lockfile 生成和更新效率高删除依赖时不需要重新解析整棵依赖树。与 npm 相比少了很多串行生命周期脚本带来的延迟。所以标题里的“1.4 秒删除 15 个依赖”并不是一个玄学数字而是 Bun 包管理器在缓存命中、并发解析、快速生成 lockfile 之后的直接体现。你可以不理解底层实现先用它跑一个测试项目对比一下 npm 和 Bun 在同样操作上的耗时感受会非常直观。3. Bun 安装与环境准备Bun 的安装方式很简单主要有三种。macOS / Linux 使用官方脚本安装curl -fsSL https://bun.sh/install | bashWindows 可以使用 PowerShell 安装powershell -c irm bun.sh/install.ps1 | iex如果你已经安装了 npm也可以直接通过 npm 方式安装npm install -g bun说明一下Windows 环境更推荐使用 WSL2 跑 Bun官方在 Windows 原生支持上已经有进展但 WSL 下的稳定性和原生体验通常更好。安装完成之后重新打开终端并验证版本bun --version如果能看到类似1.x.x的版本号说明安装成功。接着验证命令是否已经进入 PATHbun --help正常会输出 install、add、remove、run、test、build 等子命令。环境准备方面Bun 不依赖 GPU也不要求特殊显存内存占用相比 Node 没有明显增加。建议提前准备好一个空目录用于测试并确保网络可以正常访问 npm registry。如果你在公司内网环境可能需要配置镜像源这个在后面的“常见问题”部分会提到。4. 用 Bun 初始化项目并安装依赖4.1 初始化项目先创建一个叫 bun-demo 的目录进入后初始化项目mkdir bun-demo cd bun-demo bun init -y执行之后Bun 会生成package.json、index.ts、tsconfig.json和bun.lock等文件。这里注意区别npm 默认生成package-lock.jsonpnpm 生成pnpm-lock.yamlBun 默认生成bun.lock这是 Bun 自己的锁文件格式。如果你已经有一个 npm 项目也可以直接在项目目录里执行bun installBun 会读取已有的package.json并生成bun.lock。4.2 安装单个依赖添加一个简单的类型校验库 zodbun add zod执行后会看到输出速度明显比 npm 快尤其是缓存命中情况下。安装完成后package.json的 dependencies 区域会多出 zod。4.3 批量添加 15 个依赖为了复现“秒删依赖”的验证场景可以一次性添加 15 个常用依赖。这里选择一组纯 JavaScript 库bun add zod types/node chalk commander dayjs dotenv express fast-glob immer jwt-decode liquidjs lodash-es nanoid p-limit react react-dom这 15 个依赖包括了工具类、框架类、类型声明类覆盖了日常前端项目的常见结构。首次安装时Bun 会从网络下载并写入全局缓存耗时取决于网络速度第二次清空node_modules再安装时由于缓存命中速度会明显提升。安装完成后查看目录ls node_modules | wc -l你会发现 node_modules 的实际目录数量不一定等于 15因为依赖还有各自的传递依赖。这也是依赖管理里最容易被忽略的点你删除了顶层依赖不代表所有子依赖都会被垃圾回收还需要关注 lockfile 和缓存策略。4.4 删除依赖并查看耗时复现标题场景的核心命令就是bun remove。在项目里删除一个依赖time bun remove chalk这里用time测量耗时。在 macOS/Linux 的 Bash/Zsh 下time会输出 real、user、sys 三行如果你在 Windows PowerShell 下可以用Measure-CommandMeasure-Command { bun remove chalk }删除单个依赖后再次删除剩余的依赖也可以一次删除多个time bun remove commander dayjs dotenv express从实际体验来看Bun 的删除操作会直接更新 lockfile、从 node_modules 中移除对应目录并处理依赖树里不再需要的引用。整个过程不需要重新解析全部依赖所以给人的感受就是“命令刚敲完终端就已经返回”。需要说明的是测出来的绝对时间会受机器磁盘、缓存状态、依赖数量和 lockfile 复杂度影响。标题里 1.4 秒是一个特定环境下的演示值我们自己的机器上跑出来可能快一点也可能慢一点重点不是和这个数字完全一致而是对比 Bun 和 npm 在同一项目上的耗时差距。5. Bun 依赖删除为何快很多刚接触 Bun 的开发者会好奇为什么一个删除操作也能从原来的十几秒变成一两秒。拆开看主要有四个原因。第一Bun 的依赖解析是并发的。npm 在执行 install 或 remove 时需要构建完整的依赖树期间很多步骤是串行等待Bun 在解析 registry 元数据、计算依赖版本、更新 lockfile 时采用并发策略减少了大量空白等待时间。第二全局内容寻址存储。Bun 会将下载过的包内容缓存在全局目录项目安装时通过硬链接复制到node_modules而不是重新下载。删除依赖时只需要处理当前项目的 node_modules 和 lockfile不需要触碰全局缓存里的原始包。第三lockfile 更新成本更低。Bun 维护 lockfile 的方式比 npm 更轻量它不维护完整的 packages-lock 嵌套结构而是用一种更容易增量更新的格式。在删除依赖时Bun 可以快速定位哪些条目受影响避免全量重写。第四语言层面带来的基础性能优势。Bun 的核心代码使用 Zig 语言编写启动速度快系统调用开销低。删除操作涉及大量文件系统操作Bun 在这类 IO 密集场景上原生就有一定优势。理解了这些你就知道“秒删依赖”并不神秘它不是跳过依赖校验而是在解析、缓存、文件操作等环节做了大量优化。6. Bun 运行时能力验证除了包管理器Bun 另一个重要的用途是运行时。很多开发者选择 Bun 并不是为了跑bun install而是为了直接用 Bun 执行 TypeScript 文件。6.1 直接运行 TypeScript在初始化项目时Bun 已经生成了index.ts。修改文件内容const name: string Bun; console.log(hello ${name});然后直接运行bun run index.ts不需要额外安装 ts-node、不需要配置 tsconfig 的 module 选项Bun 会自动处理 TypeScript 转译。这种体验对很多写脚本、写工具函数的场景非常友好。6.2 用内置 API 开启 HTTP 服务Bun 内置了Bun.serve()可用于快速启动 HTTP 服务。新建server.tsconst server Bun.serve({ port: 3000, fetch(request) { return new Response(Hello from Bun at ${request.url}); }, }); console.log(Server listening on http://localhost:${server.port});运行bun run server.ts这时打开浏览器访问http://localhost:3000可以看到返回信息。这个能力意味着你可以不引入 Express 或 Fastify直接用内置 API 写一个小型后端服务。当然复杂业务场景仍然建议使用成熟框架但 Bun.serve 非常适合轻量任务、API 转发、本地 mock server。6.3 使用 Bun 内置测试运行器Bun 内置了 Jest 兼容的测试运行器。创建test.tsimport { test, expect } from bun:test; function add(a: number, b: number) { return a b; } test(add, () { expect(add(1, 2)).toBe(3); });运行测试bun testBun 会自动发现测试文件并输出结果。对于不需要复杂 mock 的纯函数项目Bun 内置测试器已经够用。6.4 用 Bun 打包Bun 也可以当作打包器使用。创建一个入口文件entry.tsimport { add } from ./add; console.log(add(1, 2));然后打包bun build ./entry.ts --outdir ./dist执行后Bun 会在dist目录下生成一个打包后的文件。这里要注意Bun 的打包器和 webpack/vite 的定位不完全相同它更适合生成可执行的 bundle不支持所有 webpack loader 插件生态。如果你需要完整的浏览器兼容打包还是建议继续使用 Vite 或 Webpack。7. 依赖缓存、镜像源与批量操作建议7.1 查看缓存目录Bun 的全局缓存默认放在用户主目录下。macOS/Linux 路径类似~/.bun/install/cacheWindows 下类似%USERPROFILE%\.bun\install\cache。你可以直接查看缓存目录大小du -sh ~/.bun/install/cache如果磁盘空间紧张可以使用 Bun 自带的缓存清理命令bun pm cache rm7.2 配置镜像源在国内服务器或内网环境访问默认 registry 可能较慢。Bun 支持通过环境变量或配置文件修改 registry。临时使用时可以设置环境变量BUN_CONFIG_REGISTRYhttps://registry.npmmirror.com bun install要长期配置可以编辑~/.bunfig.toml内容如下[install] registry https://registry.npmmirror.com配置完成后执行bun install它会读取该配置文件并使用指定镜像源。7.3 批量任务与 CI 集成Bun 支持在package.json中定义脚本然后用bun run执行。例如修改package.json{ scripts: { dev: bun run index.ts, test: bun test, build: bun build ./index.ts --outdir ./dist } }然后执行bun run test bun run build在 CI 场景下可以这样写一个通用示例GitHub Actions 风格steps: - uses: actions/checkoutv4 - uses: oven-sh/setup-bunv2 - run: bun install - run: bun test这里只展示通用写法实际使用时需要根据仓库目录调整。Bun 的安装脚本很快CI 里省下的时间会在多次 job 执行后体现出明显差异。8. 资源占用与性能观察方法虽然 Bun 不依赖 GPU但观察资源占用仍然是工程化的必要步骤。在本地测试时可以重点看三个指标。第一是安装耗时。在相同项目、相同缓存状态下分别执行npm install和bun install用time记录耗时。注意顺序先清空 node_modules 和 lockfile再测另一种工具避免缓存干扰。第二是磁盘占用。Bun 的全局缓存会占用额外磁盘空间但 node_modules 目录因为硬链接策略实际占用可能比 npm 更小。可以对比du -sh node_modules第三是进程内存。运行同一个 TypeScript 脚本分别在 Node.js 和 Bun 下观察内存占用。可以用/usr/bin/time -v或者 Windows 的任务管理器记录峰值内存。显存相关的问题在 Bun 这里不适用它不是 AI 推理工具也不需要 GPU。如果你的项目依赖了 ONNX、TensorFlow 等 Native 模块那需要的是 Python 环境或 Node 的 Node-API 生态这和 Bun 不是一个维度的问题。9. 常见问题与排查方法针对 Bun 使用过程中比较常见的问题下面给出排查表问题现象可能原因排查方式解决方案bun不是内部或外部命令安装后未刷新 PATH执行bun --version看是否找到重新打开终端或手动添加 Bun 目录到 PATH安装依赖速度慢默认 registry 访问慢检查网络和 registry 配置设置镜像源参考上文 bunfig.toml 配置依赖安装报错提示非包管理器错误某个依赖包含 native 构建脚本查看报错中的 install 脚本尝试用npm install安装该依赖或寻找纯 JS 替代包Windows 下执行脚本乱码或失败WSL/Bash 环境缺少或脚本格式不兼容确认是否在 PowerShell/Cmd 下执行优先使用 WSL2或用bun run包裹脚本删除依赖后 lockfile 未更新使用了较老版本的 Bun查看bun --version升级 Bunbun upgradebun install之后 node_modules 不完整存在 optionalDependencies 忽略逻辑检查.npmrc或 bunfig.toml显式指定依赖安装策略或删除配置文件重试运行某个包报Cannot find module该包依赖 Node.js 核心模块但 Bun 实现不一致查看具体缺失的模块名查找兼容替代包或换回 Node.js 运行缓存占用空间过大长期未清理全局缓存查看~/.bun/install/cache大小执行bun pm cache rm这些排查思路同样适用于 npm 和 pnpm 项目只是命令和路径不同。10. 依赖管理的工程化最佳实践把 Bun 放进工程化流程时建议遵循以下原则。第一锁文件必须提交到代码仓库。Bun 会生成bun.lock要把它和package.json一起提交。锁文件能保证团队和 CI 环境安装的依赖版本一致避免“本地能跑线上报错”的问题。第二第一次安装使用完整网络环境。Bun 的全局缓存是跨项目共享的第一次在某个项目安装时尽量保证网络稳定这样后续在其他项目安装同一依赖时会直接从缓存复制。第三删除依赖时检查 lockfile diff。执行bun remove后打开bun.lock看变更是否只影响当前依赖。如果出现了大量无关变更说明项目中存在依赖引用关系比较复杂的包需要谨慎处理。第四控制依赖数量。虽然 Bun 安装快、删除快但依赖数量膨胀仍然会拉长 CI 时间、增加供应链风险。建议周期性用bun pm ls查看依赖树上是否有无用包。第五区分开发依赖和运行依赖。用bun add -d添加开发依赖避免把构建工具、类型声明、测试框架打进生产依赖。例bun add -d typescript types/node第六在 CI 中使用与本地相同的 Bun 版本。可以在 CI 配置中固定版本号避免 Bun 升级带来的行为变化影响构建结果。11. 结尾先用一个测试项目验证删除速度这篇文章的重点其实是一句话Bun 的价值不只在“秒删依赖”而在于它把运行时、包管理、打包、测试集成到一个命令里让 JavaScript 项目的日常操作变得直接且快。建议你先别急着把公司老项目迁到 Bun。最稳妥的验证路径是创建一个空目录用bun init -y初始化批量添加 15 个依赖然后执行time bun remove对比 npm同时记录磁盘占用和 lockfile 变化。如果测试项目跑得顺畅再考虑在公司项目或 CI 流程中引入 Bun。最容易踩的坑集中在两块一是 Windows 环境没配好 WSL导致脚本或原生模块异常二是有 native 构建脚本的老依赖和 Bun 不兼容出现安装报错。遇到这类问题不要硬搬项目先用纯 JavaScript 依赖验证 Bun 的核心能力再逐步扩大范围。后续可以继续往 Bundler API、Bun.serve 后端服务、Bun 插件体系、与 docker 镜像构建结合这些方向探索。如果你目前的主要痛点是“安装依赖和删除依赖太慢”那 Bun 值得专门安排一个晚上跑一遍测试对比数据会给你答案。