🚀 为什么选择 pnpm：彻底解决 npm 的依赖地狱
在日常开发中，你是否遇到过这些诡异的问题：
- 本地运行一切正常，线上 CI 却报
Cannot find module？ - 升级某个依赖，结果其它模块突然崩了？
- 明明没写依赖，居然还能
require()成功？
这些问题的根源，大多来自于 npm 的 依赖提升（hoisting）机制。
🧨 问题引出：npm 的 hoisting 究竟干了什么？
✅ 什么是 Hoisting？
Hoisting 是 npm 默认的安装策略：它会把各层级的依赖**“提升”到项目根目录**下的 node_modules/ 中。这种做法虽然提升了安装效率，但也埋下了许多隐患。
⚠️ 三大典型踩坑场景
🚧 场景 1：隐式依赖在本地能跑，线上挂了
项目结构（使用 npm）：
perl
复制编辑
my-app/
├── node_modules/
│ ├── A/ # 你的直接依赖
│ ├── lodash/ # A 的依赖
├── package.json # 没有声明 lodash
你写了这样的代码：
js
复制编辑
const _ = require('lodash'); // ✅ 本地能跑
为什么能跑？
npm 把 lodash 提升到了根目录 node_modules/，虽然你没声明它，它依然能被解析。
但线上 CI 使用 pnpm 或 yarn --frozen-lockfile 构建时：
bash
复制编辑
Error: Cannot find module 'lodash'
✅ 结论：依赖没有声明，线上构建失败。
🚧 场景 2：依赖版本冲突导致功能异常
你安装了两个库：
json
复制编辑
{
"dependencies": {
"A": "^1.0.0",
"B": "^1.0.0"
}
}
- A 依赖
moment@2.20 - B 依赖
moment@2.29
由于 npm 提升依赖，只有一个 moment 会被安装（通常是较新的 2.29）。
结果你调用：
js
复制编辑
A.someFn(); // ❌ 崩了：moment.fn.someFn is not a function
A 依赖的老版本 API 被新版本覆盖了。
🚧 场景 3：升级依赖导致其他模块失效
你升级了 B，结果报错：
bash
复制编辑
Error: Cannot find module 'C'
因为 C 是 B 的间接依赖，而升级后 B 不再依赖它了，但你项目代码偷偷用了它。
✅ pnpm 是如何解决这些问题的？
📦 1. 严格的模块隔离结构
pnpm 不做 hoisting，每个模块只能访问自己声明的依赖。项目结构如下：
graphql
复制编辑
node_modules/
.pnpm/
A@1.0.0/
node_modules/
B@1.0.0/
node_modules/
C@1.0.0/
✅ 优点：
- 你只能使用自己在
package.json里声明的依赖 - 没写的依赖无法
require()，更安全更规范 - 模块之间互不干扰，API 不会被错误覆盖
🧩 2. 多版本共存，避免依赖污染
即使多个模块依赖不同版本的同一个库，pnpm 也能做到：
bash
复制编辑
A -> moment@2.20
B -> moment@2.29
二者完全隔离，不会互相污染，彻底解决版本冲突问题。
🔒 3. 锁文件一致 + 安装行为可预测
pnpm 默认行为等价于：
bash
复制编辑
pnpm install --frozen-lockfile
它严格遵循 pnpm-lock.yaml，不会隐式升级依赖，同时：
- CI 和本地安装行为一致 ✅
- 没写的依赖无法隐式加载 ✅
🧭 4. 精准的依赖路径查找
pnpm 使用真实的目录结构 + 符号链接（symlink）来组织依赖，查找路径更清晰、可控。
不再有 npm 的“从根目录一级一级向上找”的不确定性，每个模块只看得到自己的依赖。
📊 类比总结图
| 类比场景 | npm | pnpm |
|---|---|---|
| 厨房使用 | 所有人共用一个大锅饭 | 每个人独立做饭各用各的锅 🍲 |
| 依赖访问权限 | 想吃什么都能偷吃一点 | 只能吃自己买的 ✅ |
| 安全性 | 容易吃到别人的/过期的依赖 | 模块独立，不交叉 ✅ |
| 问题排查难度 | 谁污染了谁很难查清楚 | 问题定位精准 ✅ |
✅ 最终总结：pnpm 的三板斧
| 核心机制 | 带来的优势 |
|---|---|
| 🎯 严格依赖隔离 | 阻止隐式依赖、解决版本冲突 |
| 💾 全局缓存 + 硬链接 | 安装速度快、磁盘节省、多个项目共享依赖 ✅ |
| 🔐 严格锁定依赖版本 | CI 本地一致、不会偷偷升级、避免回归 bug ✅ |
