bun install 的安装与缓存机制：如何评估实际收益
了解 Bun 的全局缓存、平台复制策略和文本锁文件，并用冷缓存、热缓存与 CI 场景比较依赖安装成本。
Bun 的依赖安装会利用全局缓存并选择平台对应的文件复制方式。是否比现有包管理器更快，取决于网络、磁盘、依赖结构与缓存状态；不能把厂商基准的倍数直接套到自己的项目。
缓存怎样减少重复工作
安装器先检查已有依赖与缓存，缺失时再下载。比较安装耗时必须区分首次安装、已有全局缓存、已有 node_modules 三种状态；只报告一次热缓存安装不能代表 CI 的首次构建。
文件复制随平台变化
官方文档描述：Linux 与 Windows 默认采用 hardlink，macOS 使用 clonefile；底层操作失败时可以回退到复制文件。两者都减少重复数据处理，但硬链接与写时复制语义不同。容器层、跨文件系统挂载和缓存权限也会影响行为。
当前锁文件是文本格式
Bun 1.2 起默认使用文本 bun.lock，旧版 bun.lockb 才是二进制格式。锁文件负责固定依赖解析结果，全局缓存负责复用下载与文件，不能把这两者混为一种优化。团队应提交锁文件并在 CI 使用冻结模式。
bun install --frozen-lockfile
在项目中比较
固定运行时、依赖清单、registry、机器与网络，分别记录冷缓存和热缓存的耗时、峰值内存及磁盘占用。然后执行构建、测试和原生扩展加载；生命周期脚本的信任配置同样属于迁移检查。不要仅以安装成功判断兼容。
何时值得迁移
依赖安装占 CI 时间较大、多个项目可共享缓存时，适合做小范围对照。如果主要时间花在类型检查、测试或打包，先找出瓶颈。保留原锁文件和流水线配置用于回退，验证后再统一团队工具。
参考文档
本文依据官方文档整理，未对读者项目进行性能实测。
