用 Bun 管理前端小项目的依赖洁癖

快速安装是效率，不是放弃判断的理由。

Bun 很快，但快不是乱装依赖的理由。小项目最重要的是把运行时依赖、开发依赖和锁文件变更控制住，能用现有工具解决的问题就别再往项目里塞新包。

我更喜欢把 Bun 当成 项目纪律工具：安装快、脚本快、锁文件明确，但每一次依赖变更都得有理由。

先分清依赖类型

依赖最怕混。运行时真的要打进应用的包，和只在开发阶段使用的工具，不应该都塞进一个篮子里。

我通常按这个标准判断：

• 页面运行需要的包，放进 dependencies。
• 类型、格式化、构建辅助，放进 devDependencies。
• 临时排查工具，优先用 bunx。
• 只用一次的脚本，不急着变成项目依赖。

比如检查 TypeScript 不需要额外写脚本时，可以直接执行：

bunx tsc --noEmit

锁文件要认真看

bun.lock 不是噪音。只要改了依赖，就应该看锁文件变化是否符合预期。一个小包带进来十几个间接依赖，不一定错，但一定要知道。

脚本保持短而明确

项目脚本应该像工具箱标签，一眼知道干什么。lint、build、format 这些名字就够用，别搞一堆没人记得住的组合拳。

一个小项目常见脚本大概是：

{
  "scripts": {
    "dev": "next dev",
    "lint": "biome check",
    "build": "next build"
  }
}

这类脚本的优点是没有惊喜。执行 bun run lint 就是检查，不会顺手改文件；执行 bun run build 就是构建，不会偷偷发请求。

什么时候该加包

加包之前，我会先问三个问题：

1. 标准库或现有依赖能不能解决？
2. 这个包是否只服务一次性需求？
3. 维护成本是否小于自己实现的成本？

快不是乱的借口

Bun 让安装变快，是为了减少等待，不是为了降低判断标准。工具越顺手，越要把边界守住。否则项目迟早会从“小而快”变成“谁也不敢删依赖”的仓库。

依赖决策表

• 看 package.json 变更。
• 看 bun.lock 是否只多出预期依赖。
• 发布前用 Cmd + F 搜一次新增包名。

依赖洁癖不是保守，是让项目保持可解释。