在前端项目里，随着依赖数量增加，不同库可能要求同一个第三方包的不同版本，这就产生了版本冲突。前端包管理工具通过各自的依赖解析与存储策略，来缓解或解决这类问题。
为什么会出现版本冲突
当项目直接依赖 A 和 B，而 A 依赖 C@1.0，B 依赖 C@2.0 时，如果包管理工具只允许安装一个 C 版本，就可能让 A 或 B 运行出错。这种多版本共存需求是冲突的根源。
npm 的处理方式
npm 在早期使用嵌套的 node_modules 结构，每个包自己的依赖放在自身目录下，以此实现多版本共存。后来默认采用扁平化安装，把兼容版本提升到顶层，冲突版本仍嵌套存放，并配合 package-lock.json 锁定依赖树。
{
"name": "demo",
"version": "1.0.0",
"dependencies": {
"a": "1.0.0",
"b": "1.0.0"
},
"lockfileVersion": 2
}
yarn 的解决策略
yarn 同样生成 yarn.lock 保证可复现安装，并支持通过 resolutions 字段强制指定某个嵌套依赖的版本，从而统一冲突包版本。
{
"resolutions": {
"c": "2.0.0"
}
}
pnpm 的结构化方案
pnpm 使用全局内容寻址存储，项目中的 node_modules 通过硬链接引用全局包，并用符号链接组织依赖关系。同一个版本只存一次，不同版本各自隔离，从结构层面减少冲突与冗余。
| 工具 | 冲突解决特点 |
|---|---|
| npm | 扁平化加嵌套，lock 文件锁定 |
| yarn | lock 文件加 resolutions 强制版本 |
| pnpm | 全局存储与硬链接，天然隔离多版本 |
实际选择建议
如果团队追求稳定和熟悉度，npm 与 yarn 已能覆盖多数场景；若项目依赖庞大、希望节省磁盘并降低冲突概率，pnpm 是更优解。遇到冲突时可先查看 lock 文件与依赖树，再用对应工具的能力调整版本。
理解工具背后的依赖解析逻辑，比单纯执行安装命令更能从根本上规避版本冲突。