JavaScript 包管理：先统一版本来源，再讨论安装速度

JavaScript 包管理器选择地图项目声明、工具版本、依赖模型和锁文件共同决定安装结果；迁移必须同时处理入口、磁盘模型、脚本和回滚。高清原图

node --version 一致，不代表依赖安装一致。npm、pnpm、Yarn Modern 和 Bun 会以不同方式解析依赖、组织磁盘、执行生命周期脚本、保存锁文件和处理 workspace；Corepack 又只负责把项目声明映射到包管理器版本，不负责 Node.js 版本。

六条阅读路线

文章	解决什么	关键判断
npm	Node.js 常见默认包管理入口	npm ci、lockfile、registry、scripts 和 workspaces 是否形成稳定合同
pnpm	内容寻址 store 与严格链接模型	节省磁盘是否值得引入链接、hoist 和版本兼容约束
Yarn Modern	可配置 linker、workspace 与插件体系	Classic / Modern、PnP / node-modules 和零安装边界是否说清
Corepack	项目声明到包管理器版本的分发入口	Node 25 后独立安装、实验状态和供应链来源如何治理
Bun 包管理器	Bun 提供的高速依赖安装能力	现有 Node 生态兼容、bun.lock 和 linker 迁移是否可回滚
选型与迁移	四类包管理器的团队取舍	是否清除了混合 lockfile、全局入口和旧缓存假象

先确认命令、声明与锁文件

开始任何文章前，先记录：

node --version
npm --version

随后按项目实际入口检查 package.json#packageManager、锁文件、workspace 声明、.npmrc / .yarnrc.yml、Node 版本声明和 CI 安装命令。不要为了跟做而在同一仓库同时生成 package-lock.json、pnpm-lock.yaml、yarn.lock 和 bun.lock。

Node 25 起 Corepack 不再随 Node.js 分发，因此“装好 Node 就一定有 Corepack”已经不是稳定前提。团队必须明确包管理器由官方安装器、Corepack、Volta、系统包管理器还是受控基础镜像交付，并验证终端、IDE 与 CI 的实际解析路径。

共同项目事实

一个可审查的 JavaScript 项目至少应提交：

唯一包管理器声明和唯一权威 lockfile。明确的 Node.js 兼容范围与开发基线。无真实凭证的 registry / scope 模板。

可在本机和 CI 复用的 install、test、build 命令。生命周期脚本、补丁、插件和 workspace 边界的说明。包管理器升级、lockfile 重写和迁移回滚规则。

个人全局安装、用户级认证、私有 CA 路径和缓存目录不是仓库事实，不能靠提交个人配置让团队“跑起来”。

共同风险

版本漂移：同名命令来自不同 shim、全局目录或 Node 安装，导致 lockfile 被高版本重写。来源漂移：项目级与用户级 registry、scope、代理和 CA 叠加，最终依赖来自意外上游。脚本执行：install script、package manager plugin 和补丁可以执行代码；陌生仓库不能直接高权限安装。

缓存假象：热缓存掩盖源不可达、凭证过期和缺失依赖；冷缓存与受控离线验证都要保留。迁移残留：旧 lockfile、缓存、node_modules 和 CI 命令让新工具只在作者机器工作。workspace 泄漏：内部包名、路径、构建日志和私有源地址可能进入公开日志、缓存或错误报告。

团队落地检查

安装当天从对应工具的官方入口确认平台要求、配置名称和弃用提示，并把项目实际版本写入 packageManager 或等价基线。最小实验从空目录创建、安装、运行、验证到清理，不依赖作者机器历史状态。对磁盘模型、lockfile、workspace、生命周期脚本和 registry 给出工具特有解释。

迁移必须记录旧入口、转换动作、差异验证、失败停止条件和回滚路径。CI 使用与本机相同的包管理器版本和冻结安装语义，不允许自动修复 lockfile。

当问题已经从单包安装转为跨包任务图、affected 计算或远端缓存命中时，继续查看 31 Monorepo 与构建加速；这时继续调整单个包管理器的安装参数，通常解决不了任务调度层的问题。