包管理器

包管理器是前端工程化的基石。它负责依赖的安装、版本锁定、脚本执行、发布等核心工作流。从最早的 npm 到 Yarn 再到 pnpm，每一代工具都在解决上一代遗留的痛点——嵌套地狱、幽灵依赖、磁盘浪费、安装速度慢。

本文将从 npm 原理 → Yarn 演进 → pnpm 架构 → 横向对比 → 依赖管理进阶 → 面试高频题 六个维度全面拆解包管理器。

一、npm 基础与进阶

1.1 npm 安装机制

当你执行 npm install 时，npm 内部经历了以下阶段：

npm install 完整流程：

┌─────────────────────────────────────────────────────────────────┐
│                        npm install                              │
│                            ↓                                    │
│  ┌──────────────────────────────────────────────────────────┐  │
│  │ 1. 构建依赖树（Resolve）                                   │  │
│  │    - 读取 package.json 中的 dependencies                   │  │
│  │    - 读取 package-lock.json（如果存在）                     │  │
│  │    - 向 Registry 查询每个包的最新符合版本                    │  │
│  │    - 递归解析所有子依赖，构建完整依赖树                      │  │
│  └──────────────────────────────────────────────────────────┘  │
│                            ↓                                    │
│  ┌──────────────────────────────────────────────────────────┐  │
│  │ 2. 获取包（Fetch）                                         │  │
│  │    - 检查本地缓存（~/.npm/_cacache）                       │  │
│  │    - 缓存命中 → 直接使用                                    │  │
│  │    - 缓存未命中 → 从 Registry 下载 tarball                  │  │
│  │    - 下载后写入缓存                                         │  │
│  └──────────────────────────────────────────────────────────┘  │
│                            ↓                                    │
│  ┌──────────────────────────────────────────────────────────┐  │
│  │ 3. 解压到 node_modules（Extract）                          │  │
│  │    - 将 tarball 解压到 node_modules 目录                    │  │
│  │    - 根据依赖树结构决定包的放置位置                          │  │
│  │    - 处理依赖提升（hoisting）                               │  │
│  └──────────────────────────────────────────────────────────┘  │
│                            ↓                                    │
│  ┌──────────────────────────────────────────────────────────┐  │
│  │ 4. 生命周期脚本（Lifecycle Scripts）                        │  │
│  │    - 按依赖顺序执行 preinstall → install → postinstall      │  │
│  │    - 执行 prepare 脚本                                      │  │
│  └──────────────────────────────────────────────────────────┘  │
│                            ↓                                    │
│  ┌──────────────────────────────────────────────────────────┐  │
│  │ 5. 写入 lockfile                                           │  │
│  │    - 更新 package-lock.json                                 │  │
│  └──────────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────────┘

npm 的缓存机制采用的是**内容寻址（Content-Addressable）**缓存，存储在 ~/.npm/_cacache 目录下。缓存的 key 是 tarball 的 SHA-512 哈希值，这意味着相同内容只会被缓存一份。

bash

npm cache ls
npm cache clean --force
npm cache verify

1.2 node_modules 结构演进

npm v2：嵌套结构

npm v2 采用严格的嵌套结构，每个依赖的子依赖都安装在自己的 node_modules 下：

node_modules/
├── A@1.0.0/
│   └── node_modules/
│       └── C@1.0.0/
├── B@1.0.0/
│   └── node_modules/
│       └── C@1.0.0/        ← C@1.0.0 被安装了两次！
└── D@1.0.0/
    └── node_modules/
        └── C@2.0.0/

问题：

嵌套层级过深：在 Windows 上经常超过 260 字符的路径限制
大量重复安装：相同版本的包被重复安装多次，浪费磁盘空间
安装速度慢：需要下载和写入大量重复文件

npm v3+：扁平化结构

npm v3 引入了依赖提升（Hoisting），将子依赖尽可能提升到顶层 node_modules：

npm v3+ 扁平化策略：

假设依赖关系：
  App → A@1.0 → C@1.0
  App → B@1.0 → C@1.0
  App → D@1.0 → C@2.0

node_modules/
├── A@1.0.0/              ← 提升到顶层
├── B@1.0.0/              ← 提升到顶层
├── C@1.0.0/              ← C@1.0 被提升（先被解析到）
└── D@1.0.0/
    └── node_modules/
        └── C@2.0.0/      ← C@2.0 版本冲突，保留嵌套

扁平化解决了嵌套过深和重复安装的问题，但带来了新的问题——幽灵依赖（Phantom Dependencies）。

幽灵依赖问题

假设 package.json 只声明了依赖 A：
  App → A@1.0 → B@1.0

扁平化后的 node_modules：
node_modules/
├── A@1.0.0/
└── B@1.0.0/              ← 被提升到顶层

在代码中可以直接使用：
  import B from 'B'        ← 没有在 package.json 中声明，但能正常使用！

这就是幽灵依赖：你的代码依赖了一个没有在 package.json 中显式声明的包。一旦 A 升级后不再依赖 B，你的代码就会突然崩溃。

npm v7+：改进

npm v7 引入了 package-lock.json v2 格式，支持 yarn.lock 的导入，同时默认安装 peerDependencies。但核心的扁平化策略和幽灵依赖问题仍然存在。

1.3 package.json 核心字段详解

依赖分类

json

{
  "dependencies": {
    "react": "^18.2.0",
    "react-dom": "^18.2.0"
  },
  "devDependencies": {
    "typescript": "^5.0.0",
    "vitest": "^1.0.0"
  },
  "peerDependencies": {
    "react": ">=16.8.0"
  },
  "peerDependenciesMeta": {
    "react": {
      "optional": false
    }
  },
  "optionalDependencies": {
    "fsevents": "^2.3.0"
  }
}

字段	用途	何时安装	发布到 npm 时
`dependencies`	运行时必需的依赖	`npm install` 时安装	消费者安装你的包时会一并安装
`devDependencies`	仅开发时需要（构建、测试、lint）	`npm install` 时安装，`npm install --production` 时跳过	消费者不会安装
`peerDependencies`	宿主环境必须提供的依赖（插件机制）	npm v7+ 默认自动安装，npm v3-v6 仅提示警告	消费者需要自行安装
`optionalDependencies`	可选依赖，安装失败不阻断	尝试安装，失败时静默跳过	消费者安装你的包时尝试安装

peerDependencies 深入理解

peerDependencies 最常见于插件体系：

场景：你开发了一个 React 组件库 my-ui

my-ui 的 package.json:
  "peerDependencies": {
    "react": "^17.0.0 || ^18.0.0"
  }

含义：
  - my-ui 不会自己安装 React
  - 宿主项目必须提供 React 17 或 18
  - 避免同一个项目中出现多个 React 实例

  宿主项目
  ├── react@18.2.0         ← 宿主提供
  └── my-ui@1.0.0
      └── (使用宿主的 react)  ← 而不是自己安装一份

其他重要字段

json

{
  "name": "@scope/package-name",
  "version": "1.2.3",
  "main": "./dist/index.cjs",
  "module": "./dist/index.mjs",
  "types": "./dist/index.d.ts",
  "exports": {
    ".": {
      "import": "./dist/index.mjs",
      "require": "./dist/index.cjs",
      "types": "./dist/index.d.ts"
    },
    "./utils": {
      "import": "./dist/utils.mjs",
      "require": "./dist/utils.cjs"
    }
  },
  "files": ["dist"],
  "engines": {
    "node": ">=18.0.0",
    "npm": ">=9.0.0"
  },
  "sideEffects": false,
  "type": "module",
  "bin": {
    "my-cli": "./bin/cli.js"
  },
  "overrides": {
    "lodash": "4.17.21"
  }
}

字段	作用
`main`	CommonJS 入口，`require()` 时使用
`module`	ESM 入口，打包工具优先使用
`exports`	Node.js 12.11+ 的条件导出，优先级高于 `main` / `module`
`files`	发布到 npm 时包含的文件白名单
`engines`	声明运行时版本约束
`sideEffects`	标记包是否有副作用，帮助 Tree Shaking
`type`	`"module"` 表示 .js 文件按 ESM 解析
`overrides`	强制覆盖嵌套依赖的版本（npm v8.3+）

1.4 package-lock.json 的作用与结构

package-lock.json 的核心目标是确保跨环境安装的确定性。

为什么需要 lockfile？

package.json:
  "dependencies": {
    "lodash": "^4.17.0"
  }

不同时间点 npm install 的结果可能不同：

  2023-01 → lodash@4.17.15
  2023-06 → lodash@4.17.21   ← 同一份 package.json，不同结果！

lockfile 锁定确切版本：
  package-lock.json:
    "lodash": {
      "version": "4.17.21",  ← 精确到具体版本
      "resolved": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz",
      "integrity": "sha512-..."   ← 完整性校验
    }

package-lock.json v3（npm v9+）核心结构：

json

{
  "name": "my-project",
  "version": "1.0.0",
  "lockfileVersion": 3,
  "packages": {
    "": {
      "name": "my-project",
      "version": "1.0.0",
      "dependencies": {
        "express": "^4.18.0"
      }
    },
    "node_modules/express": {
      "version": "4.18.2",
      "resolved": "https://registry.npmjs.org/express/-/express-4.18.2.tgz",
      "integrity": "sha512-...",
      "dependencies": {
        "accepts": "~1.3.8",
        "body-parser": "1.20.1"
      },
      "engines": {
        "node": ">= 0.10.0"
      }
    }
  }
}

关键字段说明：

resolved：包的下载地址
integrity：SRI（Subresource Integrity）哈希，用于验证包的完整性
lockfileVersion：锁文件格式版本，v3 删除了冗余的 dependencies 字段

最佳实践： package-lock.json 应当提交到版本控制，且不应手动编辑。

1.5 语义化版本（SemVer）

语义化版本格式为 MAJOR.MINOR.PATCH：

版本号：1.2.3

  1        .       2       .       3
  ↑                ↑               ↑
MAJOR           MINOR           PATCH
不兼容的       向后兼容的       向后兼容的
API 变更       功能新增         Bug 修复


预发布版本：
  1.0.0-alpha.1    → 内部测试
  1.0.0-beta.1     → 公测
  1.0.0-rc.1       → 候选发布

构建元数据：
  1.0.0+20230615   → 不影响版本优先级

npm 版本范围语法：

语法	含义	示例	匹配范围
`^1.2.3`	兼容补丁和次版本更新	`^1.2.3`	`>=1.2.3 <2.0.0`
`~1.2.3`	仅兼容补丁更新	`~1.2.3`	`>=1.2.3 <1.3.0`
`1.2.3`	精确版本	`1.2.3`	仅 `1.2.3`
`*`	任意版本	`*`	`>=0.0.0`
`>=1.2.3`	大于等于指定版本	`>=1.2.3`	`>=1.2.3`
`1.2.x`	补丁版本任意	`1.2.x`	`>=1.2.0 <1.3.0`
`1.2.3 - 2.0.0`	范围	-	`>=1.2.3 <=2.0.0`
`1.2.3 \|\| >=2.0.0`	或运算	-	`1.2.3` 或 `>=2.0.0`

^（caret）的特殊规则：

^1.2.3  →  >=1.2.3 <2.0.0     (正常情况)
^0.2.3  →  >=0.2.3 <0.3.0     (主版本为 0 时，次版本变化视为不兼容)
^0.0.3  →  >=0.0.3 <0.0.4     (主版本和次版本都为 0 时，锁定补丁)

这意味着 ^0.x.x 比预期更严格，因为 0.x 阶段的 API 被认为是不稳定的。

1.6 npm scripts 生命周期钩子

npm scripts 提供了一套完整的生命周期钩子系统：

npm install 生命周期：

  preinstall
       ↓
    install
       ↓
  postinstall
       ↓
  prepublish (已废弃，仅在 npm install 时触发)
       ↓
    prepare


npm publish 生命周期：

  prepublishOnly
       ↓
   prepack
       ↓
    pack
       ↓
   postpack
       ↓
   publish
       ↓
  postpublish


npm run <script> 生命周期：

  pre<script>
       ↓
   <script>
       ↓
  post<script>

常见用法：

json

{
  "scripts": {
    "prebuild": "rm -rf dist",
    "build": "tsc && vite build",
    "postbuild": "cp package.json dist/",

    "pretest": "npm run lint",
    "test": "vitest run",

    "prepare": "husky install",
    "prepublishOnly": "npm run test && npm run build",

    "lint": "eslint src --ext .ts,.tsx",
    "format": "prettier --write src"
  }
}

钩子	触发时机	典型用途
`prepare`	`npm install` 之后、`npm publish` 之前	安装 Git Hooks（Husky）、编译 TypeScript
`prepublishOnly`	仅 `npm publish` 之前	运行测试和构建，确保发布质量
`preinstall`	`npm install` 之前	强制使用特定包管理器
`postinstall`	`npm install` 之后	原生模块编译、补丁应用

强制包管理器的常见技巧：

json

{
  "scripts": {
    "preinstall": "npx only-allow pnpm"
  }
}

二、Yarn

2.1 Yarn Classic（v1）

Yarn 由 Facebook 于 2016 年发布，旨在解决当时 npm 的三大痛点：

安装速度慢：Yarn 引入了并行安装和离线缓存
安装结果不确定：Yarn 引入了 yarn.lock 锁文件
安全性不足：Yarn 引入了完整性校验

Yarn Classic vs npm（当时对比）：

┌──────────────┬───────────────────┬───────────────────┐
│     特性      │     npm (v3-v5)   │   Yarn Classic    │
├──────────────┼───────────────────┼───────────────────┤
│  安装策略     │  串行下载          │  并行下载          │
│  锁文件      │  npm v5 前无       │  yarn.lock（首创） │
│  离线模式     │  不支持            │  支持              │
│  确定性安装   │  npm v5 后支持     │  一开始就支持      │
│  Workspaces  │  npm v7 后支持     │  v1.0 就支持       │
└──────────────┴───────────────────┴───────────────────┘

yarn.lock 示例：

yaml

lodash@^4.17.0:
  version "4.17.21"
  resolved "https://registry.yarnpkg.com/lodash/-/lodash-4.17.21.tgz#679591c564c3bffaae8454cf0b3df370c3d6911c"
  integrity sha512-v2kDEe57lecTulaDIuNTPy3Ry4gLGJ6Z1O3vE1krgXZNrsQ+LFTGHVxVjcXPs17LhbZVGedAJv8XZ1tvj5FvSg==

2.2 Yarn Berry（v2+）

Yarn Berry 是 Yarn 的彻底重写版本，带来了全新的架构和理念。最核心的变革是 Plug'n'Play（PnP）。

PnP 原理

传统的 Node.js 模块解析依赖 node_modules 目录和文件系统的目录遍历：

传统 Node.js 模块解析：

require('lodash')
    ↓
  在当前目录的 node_modules 中查找
    ↓ (未找到)
  在父目录的 node_modules 中查找
    ↓ (未找到)
  继续向上遍历...
    ↓
  直到根目录

问题：
  1. 大量文件系统 I/O 操作（stat, readdir）
  2. node_modules 包含数万个文件，占用大量磁盘空间
  3. 安装时需要解压数万个文件到磁盘

Yarn PnP 的解决方案：完全移除 node_modules，用一个 .pnp.cjs 文件记录所有依赖的映射关系：

Yarn PnP 模块解析：

require('lodash')
    ↓
  查询 .pnp.cjs 中的映射表
    ↓
  直接定位到 .yarn/cache/lodash-npm-4.17.21-xxxx.zip
    ↓
  从 zip 包中读取文件

优势：
  1. 单次查表操作，无需文件系统遍历
  2. 依赖以 zip 包形式存储，文件数量从数万降到数百
  3. 安装速度极快（无需解压）
  4. 严格的依赖访问控制（杜绝幽灵依赖）

.pnp.cjs 核心结构简化示意：

const pnpData = {
  packageRegistryData: [
    [null, [
      [null, {
        packageLocation: './',
        packageDependencies: [
          ['lodash', 'npm:4.17.21'],
          ['react', 'npm:18.2.0'],
        ],
      }],
    ]],
    ['lodash', [
      ['npm:4.17.21', {
        packageLocation: './.yarn/cache/lodash-npm-4.17.21-xxxx.zip/node_modules/lodash/',
        packageDependencies: [],
      }],
    ]],
  ],
};

零安装（Zero-Installs）

PnP 模式下，所有依赖都以 zip 包形式存储在 .yarn/cache 目录。由于 zip 包数量少、体积小，可以直接提交到 Git 仓库：

.yarn/
├── cache/
│   ├── lodash-npm-4.17.21-xxxx.zip       (67KB)
│   ├── react-npm-18.2.0-xxxx.zip         (85KB)
│   └── typescript-npm-5.0.0-xxxx.zip     (12MB)
├── releases/
│   └── yarn-4.0.0.cjs
└── .pnp.cjs

提交到 Git 后：
  - git clone 之后无需 yarn install
  - CI 环境无需安装步骤
  - 完全消除安装不确定性

2.3 .yarnrc.yml 配置

yaml

nodeLinker: pnp

yarnPath: .yarn/releases/yarn-4.0.0.cjs

npmRegistryServer: "https://registry.npmmirror.com"

npmScopes:
  my-company:
    npmRegistryServer: "https://npm.my-company.com"
    npmAuthToken: "${NPM_AUTH_TOKEN}"

pnpMode: strict

enableGlobalCache: false

plugins:
  - path: .yarn/plugins/@yarnpkg/plugin-interactive-tools.cjs
    spec: "@yarnpkg/plugin-interactive-tools"

配置项	说明
`nodeLinker`	`pnp`（默认）、`pnpm`、`node-modules`
`yarnPath`	项目级 Yarn 二进制，确保团队使用同一版本
`pnpMode`	`strict`（严格禁止幽灵依赖）、`loose`（兼容模式）
`enableGlobalCache`	是否使用全局缓存（关闭时使用项目级缓存，适合 Zero-Installs）

2.4 PnP 模式与 node_modules 模式对比

Yarn Berry 两种模式：

┌──────────────────────────────────────────────────────────┐
│                     PnP 模式（推荐）                       │
│                                                          │
│  项目目录/                                                │
│  ├── .pnp.cjs              ← 依赖映射表                  │
│  ├── .yarn/                                              │
│  │   └── cache/             ← zip 格式的依赖包            │
│  ├── package.json                                        │
│  └── yarn.lock                                           │
│                                                          │
│  ✅ 安装极快   ✅ 严格依赖   ✅ 零安装   ✅ 文件数少       │
│  ❌ 部分工具不兼容（需要适配）                              │
└──────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────┐
│                   node_modules 模式                       │
│                                                          │
│  项目目录/                                                │
│  ├── node_modules/          ← 传统目录结构                │
│  ├── package.json                                        │
│  └── yarn.lock                                           │
│                                                          │
│  ✅ 兼容性好   ✅ 无需额外配置                              │
│  ❌ 安装较慢   ❌ 幽灵依赖   ❌ 磁盘占用大                  │
└──────────────────────────────────────────────────────────┘

切换模式：

yaml

# .yarnrc.yml
nodeLinker: node-modules

bash

yarn install

三、pnpm

3.1 核心架构

pnpm（performant npm）的核心设计理念是内容寻址存储 + 硬链接 + 符号链接，从根本上解决了 npm / Yarn Classic 的磁盘浪费和幽灵依赖问题。

pnpm 的存储架构：

全局 Store（内容寻址存储）
~/.local/share/pnpm/store/v3/
└── files/
    ├── 00/
    │   ├── a1b2c3d4...    ← 文件内容的 SHA-512 哈希
    │   └── e5f6g7h8...
    ├── 01/
    │   ├── i9j0k1l2...
    │   └── m3n4o5p6...
    └── ...

每个文件只存储一份！
lodash@4.17.21 中的 lodash.js 文件
  → 计算内容哈希
  → 存储为 store/v3/files/xx/hash...
  → 所有项目共享这一份文件

项目级 node_modules 结构：

项目 A 和项目 B 都依赖 lodash@4.17.21：

┌──────────────────────────────────────────────────────┐
│                    全局 Store                          │
│                                                      │
│  lodash.js → store/v3/files/ab/cd1234...             │
│                    ↑                ↑                  │
│               硬链接(HL)        硬链接(HL)             │
│                    │                │                  │
│  ┌─────────────────┼──┐  ┌──────────┼───────────┐    │
│  │    项目 A        │  │  │   项目 B  │           │    │
│  │ node_modules/    │  │  │ node_modules/        │    │
│  │  .pnpm/          │  │  │  .pnpm/              │    │
│  │   lodash@4.17.21/│  │  │   lodash@4.17.21/    │    │
│  │    lodash.js  ───┘  │  │    lodash.js  ───────┘    │
│  └─────────────────────┘  └──────────────────────┘    │
│                                                      │
│  磁盘上只有一份 lodash.js！                             │
└──────────────────────────────────────────────────────┘

3.2 非扁平化的 node_modules 结构

pnpm 的 node_modules 采用三层结构：

假设依赖关系：
  App → express@4.18.2
  express → accepts@1.3.8
  express → body-parser@1.20.1

pnpm 创建的 node_modules 结构：

node_modules/
├── express → .pnpm/express@4.18.2/node_modules/express    ← 符号链接
├── .pnpm/
│   ├── express@4.18.2/
│   │   └── node_modules/
│   │       ├── express/           ← 硬链接到全局 Store
│   │       │   ├── index.js       ← 硬链接
│   │       │   ├── lib/
│   │       │   └── package.json
│   │       ├── accepts → ../../accepts@1.3.8/node_modules/accepts
│   │       └── body-parser → ../../body-parser@1.20.1/node_modules/body-parser
│   ├── accepts@1.3.8/
│   │   └── node_modules/
│   │       └── accepts/           ← 硬链接到全局 Store
│   └── body-parser@1.20.1/
│       └── node_modules/
│           └── body-parser/       ← 硬链接到全局 Store
└── .modules.yaml

三层结构解释：

第一层：node_modules/ 顶层
  └── 只包含 package.json 中直接声明的依赖的符号链接
      → 杜绝幽灵依赖！

第二层：node_modules/.pnpm/
  └── 所有包的「虚拟存储」目录
      → 以 <包名>@<版本号> 命名
      → 每个包自己的 node_modules 下通过符号链接引用自己的依赖

第三层：全局 Store
  └── 文件的真实存储位置
      → 通过硬链接被各项目引用
      → 跨项目共享，节省磁盘空间

为什么这个结构能解决幽灵依赖？

传统扁平化（npm/yarn）：
  node_modules/
  ├── express/
  ├── accepts/         ← 被提升到顶层，代码可以直接 require('accepts')
  └── body-parser/     ← 被提升到顶层

pnpm 非扁平化：
  node_modules/
  ├── express → ...    ← 只有 express 在顶层
  └── .pnpm/
      └── ...          ← accepts 和 body-parser 藏在 .pnpm 深处

require('accepts')  →  在 node_modules/ 顶层找不到！→ 报错！
require('express')  →  找到符号链接 → 正常工作 ✅

3.3 pnpm 安装流程

pnpm install 完整流程：

┌──────────────────────────────────────────────────────────┐
│                     pnpm install                          │
│                          ↓                                │
│  ┌────────────────────────────────────────────────────┐  │
│  │ 1. 解析依赖                                         │  │
│  │    - 读取 package.json + pnpm-lock.yaml             │  │
│  │    - 计算依赖图                                      │  │
│  └────────────────────────────────────────────────────┘  │
│                          ↓                                │
│  ┌────────────────────────────────────────────────────┐  │
│  │ 2. 获取包                                           │  │
│  │    - 检查全局 Store 是否已有该版本                     │  │
│  │    - 有 → 跳过下载                                    │  │
│  │    - 无 → 下载 tarball → 解压 → 计算文件哈希          │  │
│  │         → 存入全局 Store（内容寻址）                   │  │
│  └────────────────────────────────────────────────────┘  │
│                          ↓                                │
│  ┌────────────────────────────────────────────────────┐  │
│  │ 3. 链接依赖                                         │  │
│  │    - 在 node_modules/.pnpm/ 下创建目录结构           │  │
│  │    - 从全局 Store 创建硬链接到 .pnpm/                 │  │
│  │    - 创建符号链接连接各包之间的依赖关系                 │  │
│  │    - 在 node_modules/ 顶层创建直接依赖的符号链接       │  │
│  └────────────────────────────────────────────────────┘  │
│                          ↓                                │
│  ┌────────────────────────────────────────────────────┐  │
│  │ 4. 写入 pnpm-lock.yaml                              │  │
│  └────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────┘

3.4 .npmrc 配置

pnpm 通过 .npmrc 文件进行配置：

ini

registry=https://registry.npmmirror.com

store-dir=~/.local/share/pnpm/store

shamefully-hoist=false

strict-peer-dependencies=true

auto-install-peers=true

node-linker=hoisted

public-hoist-pattern[]=*eslint*
public-hoist-pattern[]=*prettier*

配置项	默认值	说明
`store-dir`	`~/.local/share/pnpm/store`	全局 Store 路径
`shamefully-hoist`	`false`	设为 `true` 时模拟 npm 的扁平化结构（不推荐）
`strict-peer-dependencies`	`false`	严格模式下 peerDep 不满足会报错
`auto-install-peers`	`true`（v8+）	自动安装 peerDependencies
`node-linker`	`isolated`	`isolated`（默认非扁平）、`hoisted`（扁平化）
`public-hoist-pattern`	-	允许特定包提升到顶层（解决工具兼容性）

3.5 pnpm Store 管理

bash

pnpm store status

pnpm store prune

pnpm store path

pnpm Store 管理示意：

~/.local/share/pnpm/store/v3/
├── files/
│   ├── 00/
│   │   ├── a1b2c3...  (lodash/lodash.js)
│   │   └── d4e5f6...  (lodash/package.json)
│   ├── 01/
│   │   └── ...
│   └── ff/
│       └── ...
└── tmp/

pnpm store prune:
  - 扫描所有引用计数为 0 的文件
  - 删除不再被任何项目引用的内容
  - 释放磁盘空间

四、三大包管理器对比

4.1 核心对比表

维度	npm	Yarn Classic	Yarn Berry (PnP)	pnpm
node_modules 结构	扁平化	扁平化	无 node_modules	非扁平化（符号链接）
安装速度	较慢	快	极快（零安装）	快
磁盘占用	大（每项目独立副本）	大	小（zip 缓存）	极小（硬链接共享）
幽灵依赖	❌ 存在	❌ 存在	✅ 杜绝	✅ 杜绝
锁文件	package-lock.json	yarn.lock	yarn.lock	pnpm-lock.yaml
锁文件格式	JSON	自定义	YAML	YAML
Monorepo 支持	Workspaces (v7+)	Workspaces	Workspaces	Workspaces + Catalog
安全性	npm audit	yarn audit	yarn audit	pnpm audit
Node.js 内置	✅ 是	❌ 否（Corepack）	❌ 否（Corepack）	❌ 否（Corepack）
插件系统	❌ 无	❌ 无	✅ 有	❌ 无
Patch 协议	❌ 无	✅ patch:	✅ patch:	✅ pnpm patch

4.2 安装速度对比

基准测试场景：中型 React 项目（~200 依赖）

┌────────────────────────────────────────────────────────┐
│                   冷启动（无缓存）                        │
│                                                        │
│  npm     ████████████████████████████████  32s          │
│  yarn    ██████████████████████████        26s          │
│  pnpm    █████████████████                 17s          │
│  yarn pnp████████████                     12s          │
│                                                        │
│                   热启动（有缓存）                        │
│                                                        │
│  npm     ██████████████████                18s          │
│  yarn    ████████████                     12s          │
│  pnpm    ████                              4s          │
│  yarn pnp██                                2s          │
│                                                        │
│                   有 lockfile + 有缓存                   │
│                                                        │
│  npm     ████████████                     12s          │
│  yarn    ████████                          8s          │
│  pnpm    ███                               3s          │
│  yarn pnp                                  0s (零安装)  │
└────────────────────────────────────────────────────────┘

4.3 磁盘占用对比

同一份依赖（lodash@4.17.21）在 10 个项目中的磁盘占用：

npm:    1.4MB × 10 = 14MB     (每个项目独立副本)
yarn:   1.4MB × 10 = 14MB     (每个项目独立副本)
pnpm:   1.4MB × 1  = 1.4MB    (全局 Store 一份，硬链接引用)

100 个依赖 × 10 个项目：
  npm/yarn:  ~500MB × 10 = ~5GB
  pnpm:      ~500MB × 1  = ~500MB + 少量链接开销

4.4 Corepack

Corepack 是 Node.js 16.9+ 内置的包管理器管理工具，用于确保团队使用一致的包管理器版本。

bash

corepack enable

corepack prepare pnpm@9.0.0 --activate

corepack prepare yarn@4.0.0 --activate

在 package.json 中声明：

json

{
  "packageManager": "pnpm@9.0.0"
}

Corepack 工作原理：

执行 pnpm install
      ↓
  Corepack 拦截
      ↓
  读取 package.json 中的 packageManager 字段
      ↓
  检查本地是否有 pnpm@9.0.0
      ↓ (没有)
  自动下载 pnpm@9.0.0
      ↓
  使用 pnpm@9.0.0 执行 install

优势：
  - 团队成员无需手动安装/切换包管理器版本
  - 版本锁定在 package.json 中，跟随项目走
  - CI 环境自动使用正确版本

五、依赖管理进阶

5.1 依赖提升（Hoisting）与幽灵依赖（Phantom Dependencies）

依赖提升的本质：

原始依赖树：
  App
  ├── A@1.0
  │   ├── C@1.0
  │   └── D@2.0
  └── B@1.0
      ├── C@1.0
      └── D@1.0

扁平化提升后（npm/yarn）：
  node_modules/
  ├── A@1.0
  ├── B@1.0
  ├── C@1.0          ← 提升（A 和 B 共用）
  ├── D@2.0          ← 提升（先遇到的版本 or 更多依赖使用的版本）
  └── B/
      └── node_modules/
          └── D@1.0  ← 版本冲突，保留嵌套

提升策略的不确定性：
  D@2.0 还是 D@1.0 被提升取决于安装顺序！
  不同版本的 npm 可能产生不同的提升结果。

幽灵依赖的真实案例：

场景：某前端项目依赖 webpack

package.json:
  "devDependencies": {
    "webpack": "^5.88.0"
  }

webpack 内部依赖 acorn：
  webpack → acorn@8.10.0

扁平化后 acorn 被提升到顶层

开发者在代码中直接使用了 acorn：
  const acorn = require('acorn')

一切正常... 直到 webpack 升级后不再依赖 acorn：
  npm install → acorn 不再安装 → 项目崩溃！

解决方案：
  1. pnpm 非扁平化结构（根本解决）
  2. Yarn PnP strict 模式（根本解决）
  3. eslint-plugin-import 的 no-extraneous-dependencies 规则（开发时检测）

5.2 依赖地狱（Dependency Hell）

依赖地狱场景：

项目依赖：
  App → pkg-A → lodash@3.x
  App → pkg-B → lodash@4.x
  App → pkg-C → lodash@4.x

npm 的处理（扁平化）：
  node_modules/
  ├── lodash@4.x          ← 提升（更多包使用 v4）
  ├── pkg-A/
  │   └── node_modules/
  │       └── lodash@3.x  ← 嵌套安装
  ├── pkg-B/
  └── pkg-C/

问题：
  1. lodash 有两份，占用额外空间
  2. 如果 pkg-A 和 App 同时操作 lodash 对象，可能产生类型不兼容
  3. 如果 lodash 有单例逻辑（如全局缓存），两个版本互不共享

更严重的场景（菱形依赖 + peerDep）：
  App → A → C@^1.0 (peerDep: React@17)
  App → B → C@^1.0 (peerDep: React@18)
  App → React@18

  C@1.0 被提升到顶层，但它到底用 React 17 还是 18？

npm 的 overrides 和 pnpm 的 overrides 是解决版本冲突的手段：

json

{
  "overrides": {
    "lodash": "4.17.21"
  }
}

pnpm 的 pnpm.overrides：

json

{
  "pnpm": {
    "overrides": {
      "lodash": "4.17.21",
      "foo@^2.0.0>bar": "1.0.0"
    }
  }
}

Yarn 的 resolutions：

json

{
  "resolutions": {
    "lodash": "4.17.21",
    "**/bar": "1.0.0"
  }
}

5.3 依赖锁定策略

依赖锁定最佳实践：

┌────────────────────────────────────────────────────────┐
│                    应用项目（App）                       │
│                                                        │
│  ✅ 提交 lockfile 到 Git                                │
│  ✅ CI 使用 npm ci / yarn --frozen-lockfile /           │
│     pnpm install --frozen-lockfile                     │
│  ✅ 定期更新依赖（人工审查 + 自动化工具）                  │
│  ✅ 使用 ^ 范围允许补丁更新                               │
│                                                        │
│  为什么？                                                │
│  - 确保所有环境安装完全相同的依赖版本                      │
│  - lockfile 是「安装结果的快照」                          │
└────────────────────────────────────────────────────────┘

┌────────────────────────────────────────────────────────┐
│                   库项目（Library）                      │
│                                                        │
│  ✅ 提交 lockfile（用于开发环境一致性）                    │
│  ⚠️  发布到 npm 时 lockfile 不会被消费者使用              │
│  ✅ peerDependencies 范围尽量宽松                        │
│  ✅ dependencies 范围合理（^ 或 ~）                      │
│                                                        │
│  为什么？                                                │
│  - 库的 lockfile 不影响消费者                             │
│  - 消费者使用自己的 lockfile 解析版本                     │
│  - peerDep 范围太窄会限制消费者的版本选择                  │
└────────────────────────────────────────────────────────┘

npm ci vs npm install 的区别：

行为	`npm install`	`npm ci`
读取 lockfile	优先参考，但可能更新	严格按照 lockfile 安装
更新 lockfile	会更新	不会更新，不匹配则报错
node_modules	增量更新	先删除再全新安装
package.json 不匹配	更新 lockfile	直接报错
适用场景	开发环境	CI/CD 环境

5.4 安全审计

bash

npm audit

npm audit --json

npm audit fix

npm audit fix --force

npm audit --audit-level=high

npm audit 输出示例：

┌───────────────┬──────────────────────────────────────┐
│  High         │ Prototype Pollution in lodash         │
├───────────────┼──────────────────────────────────────┤
│  Package      │ lodash                                │
│  Patched in   │ >=4.17.21                            │
│  Dependency of│ my-package                            │
│  Path         │ my-package > some-lib > lodash        │
│  More info    │ https://npmjs.com/advisories/1065     │
└───────────────┴──────────────────────────────────────┘

found 3 vulnerabilities (1 low, 1 moderate, 1 high)
  run `npm audit fix` to fix them

常用安全工具：

工具	特点
`npm audit`	npm 内置，检查已知漏洞数据库
`pnpm audit`	pnpm 内置，同 npm audit
`yarn npm audit`	Yarn Berry 内置
Snyk	商业工具，漏洞库更全，支持修复建议和 PR 自动创建
Socket.dev	检测供应链攻击，分析包行为而非仅依赖已知漏洞
OSV-Scanner	Google 开源，支持多语言生态

5.5 依赖更新

npm-check-updates (ncu)

bash

npx npm-check-updates

npx npm-check-updates -u

npx npm-check-updates --target minor

npx npm-check-updates --interactive

ncu 输出示例：

Checking /path/to/package.json
[====================] 15/15 100%

 react           ^17.0.2  →   ^18.2.0
 typescript      ^4.9.0   →   ^5.3.0
 eslint          ^8.0.0   →   ^9.0.0
 vitest          ^0.34.0  →   ^1.2.0

Run ncu -u to upgrade package.json

自动化依赖更新

Renovate vs Dependabot 对比：

┌──────────────────┬────────────────────┬────────────────────┐
│     特性          │     Renovate       │    Dependabot      │
├──────────────────┼────────────────────┼────────────────────┤
│  平台支持         │  GitHub/GitLab/    │  仅 GitHub          │
│                  │  Bitbucket/Azure   │                    │
│  配置灵活度       │  极高（JSON 配置）  │  中等（YAML 配置）  │
│  分组更新         │  ✅ 支持            │  ✅ 支持（v2+）     │
│  自动合并         │  ✅ 支持            │  ✅ 支持            │
│  Monorepo 支持   │  ✅ 优秀            │  ⚠️ 有限            │
│  自托管          │  ✅ 支持            │  ❌ 不支持           │
│  更新策略         │  Pin/Range/Replace │  有限               │
│  调度策略         │  灵活（cron 表达式）│  每日/每周/每月      │
└──────────────────┴────────────────────┴────────────────────┘

Renovate 配置示例（renovate.json）：

json

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended"],
  "packageRules": [
    {
      "matchUpdateTypes": ["minor", "patch"],
      "automerge": true
    },
    {
      "matchPackagePatterns": ["eslint"],
      "groupName": "eslint"
    },
    {
      "matchUpdateTypes": ["major"],
      "labels": ["breaking-change"]
    }
  ],
  "schedule": ["after 10pm and before 5am every weekday", "every weekend"]
}

Dependabot 配置示例（.github/dependabot.yml）：

yaml

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10
    groups:
      dev-dependencies:
        dependency-type: "development"
        update-types:
          - "minor"
          - "patch"

六、Monorepo 与包管理器

6.1 Workspaces

三大包管理器都支持 Workspaces，用于在单仓库中管理多个包：

npm Workspaces（package.json）：

json

{
  "workspaces": [
    "packages/*",
    "apps/*"
  ]
}

Yarn Workspaces（package.json）：

json

{
  "workspaces": [
    "packages/*",
    "apps/*"
  ]
}

pnpm Workspaces（pnpm-workspace.yaml）：

yaml

packages:
  - 'packages/*'
  - 'apps/*'
  - '!**/test/**'

Monorepo 典型结构：

my-monorepo/
├── package.json              ← 根配置 + workspaces 声明
├── pnpm-workspace.yaml       ← pnpm 专用
├── pnpm-lock.yaml            ← 唯一的锁文件
├── packages/
│   ├── ui/
│   │   ├── package.json      ← @my/ui
│   │   └── src/
│   ├── utils/
│   │   ├── package.json      ← @my/utils
│   │   └── src/
│   └── config/
│       ├── package.json      ← @my/config
│       └── src/
└── apps/
    ├── web/
    │   ├── package.json      ← 依赖 @my/ui, @my/utils
    │   └── src/
    └── api/
        ├── package.json      ← 依赖 @my/utils
        └── src/

Workspace 内部包引用：

json

{
  "name": "@my/web",
  "dependencies": {
    "@my/ui": "workspace:*",
    "@my/utils": "workspace:^1.0.0"
  }
}

pnpm 的 workspace: 协议在发布时会自动转换：

开发时：  "@my/utils": "workspace:^1.0.0"
发布后：  "@my/utils": "^1.0.0"

开发时：  "@my/utils": "workspace:*"
发布后：  "@my/utils": "1.2.3"  (当前版本)

6.2 pnpm Catalogs（v9.5+）

pnpm Catalogs 允许在 Monorepo 中统一管理依赖版本：

yaml

# pnpm-workspace.yaml
packages:
  - 'packages/*'

catalog:
  react: ^18.2.0
  react-dom: ^18.2.0
  typescript: ^5.3.0

catalogs:
  react17:
    react: ^17.0.2
    react-dom: ^17.0.2

在子包中使用：

json

{
  "dependencies": {
    "react": "catalog:",
    "react-dom": "catalog:"
  }
}

json

{
  "dependencies": {
    "react": "catalog:react17",
    "react-dom": "catalog:react17"
  }
}

Catalogs 解决的问题：

传统方式（版本散落在各子包）：
  packages/ui/package.json:      "react": "^18.2.0"
  packages/web/package.json:     "react": "^18.2.0"
  packages/mobile/package.json:  "react": "^18.2.0"
  → 更新 React 时需要改 N 个文件

Catalogs 方式（集中管理）：
  pnpm-workspace.yaml:           catalog: { react: "^18.3.0" }
  packages/ui/package.json:      "react": "catalog:"
  packages/web/package.json:     "react": "catalog:"
  packages/mobile/package.json:  "react": "catalog:"
  → 更新 React 只需改一处

七、面试高频问题

Q1：npm install 的完整流程是什么？

回答思路：

分阶段描述：① 构建依赖树（读取 package.json 和 lockfile，向 Registry 查询版本，递归解析依赖）→ ② 获取包（检查缓存，命中则使用缓存，未命中则下载 tarball 并写入缓存）→ ③ 解压到 node_modules（根据提升策略决定包的位置）→ ④ 执行生命周期脚本（preinstall → install → postinstall → prepare）→ ⑤ 更新 lockfile。

追问： npm install 和 npm ci 的区别？

核心区别：npm ci 严格按照 lockfile 安装，不会更新 lockfile，安装前会先删除 node_modules。适合 CI 环境确保安装确定性。npm install 会尝试解析最新符合版本并可能更新 lockfile，适合开发环境。

Q2：pnpm 为什么比 npm/yarn 快且省空间？

回答思路：

两个核心机制：

内容寻址存储 + 硬链接：所有包文件按内容哈希存储在全局 Store 中，项目中的 node_modules 通过硬链接指向 Store。同一个文件在磁盘上只有一份物理存储，多个项目共享。硬链接不占用额外 inode 之外的空间。
符号链接构建依赖关系：node_modules/.pnpm/ 下的包之间通过符号链接连接依赖关系，顶层 node_modules/ 只有直接依赖的符号链接。创建符号链接比复制文件快得多。

追问： 硬链接和符号链接的区别？

硬链接是文件系统层面的多个「入口指向同一个 inode」，删除其中一个不影响其他，不能跨文件系统。符号链接是一个特殊文件，存储的是目标路径字符串，类似快捷方式，可以跨文件系统但目标删除后会变成「断链」。

Q3：什么是幽灵依赖？如何解决？

回答思路：

幽灵依赖是指代码中使用了没有在 package.json 中显式声明的包。这是 npm/Yarn Classic 扁平化策略的副作用——子依赖被提升到顶层后，应用代码可以直接 require 或 import 这些包，但它们实际上不是你的直接依赖。

危害：当上游依赖升级后不再依赖该包时，你的代码会突然崩溃。

解决方案：

pnpm：非扁平化 node_modules 结构，顶层只有直接依赖的符号链接
Yarn PnP strict 模式：严格按 package.json 声明控制依赖访问
ESLint 规则：import/no-extraneous-dependencies 在开发时检测

Q4：^1.2.3 和 ~1.2.3 有什么区别？^0.2.3 呢？

回答思路：

^1.2.3：允许更新次版本和补丁版本，范围 >=1.2.3 <2.0.0。含义是「兼容 1.x.x 的最新版本」
~1.2.3：仅允许更新补丁版本，范围 >=1.2.3 <1.3.0。含义是「接近 1.2.x 的最新版本」
^0.2.3：特殊情况！主版本为 0 表示 API 不稳定，此时 ^ 行为类似 ~，范围 >=0.2.3 <0.3.0
^0.0.3：更特殊，等同于精确版本 0.0.3，范围 >=0.0.3 <0.0.4

追问： 为什么默认是 ^ 而不是 ~？

因为 SemVer 规范规定次版本升级是向后兼容的功能添加，^ 可以自动获取新功能和 bug 修复，同时保证不引入破坏性变更。这在大多数情况下是合理的权衡。

Q5：Yarn PnP 的工作原理是什么？有什么优缺点？

回答思路：

PnP 用一个 .pnp.cjs 映射文件取代了 node_modules 目录。它记录了所有包的名称、版本、存储位置（.yarn/cache/ 中的 zip 包）以及每个包被允许访问的依赖列表。Node.js 启动时加载这个映射文件，模块解析时直接查表，无需遍历文件系统。

优点：

安装极快（无需解压文件到 node_modules）
可实现零安装（zip 缓存提交到 Git）
完全杜绝幽灵依赖
减少文件数量，Git 操作更快

缺点：

部分工具需要适配（如 React Native、Electron 等）
需要通过 @yarnpkg/sdks 配置 IDE 支持
调试时查看 zip 包中的源码不如直接查看 node_modules 方便
社区生态兼容性仍在改善中

Q6：peerDependencies 是什么？什么场景下使用？

回答思路：

peerDependencies 表示「我的包需要宿主环境提供的依赖」，最常见于插件体系。比如一个 React 组件库，它不应该自己安装 React（否则可能导致两个 React 实例共存），而是要求使用者的项目中必须已有 React。

典型使用场景：

UI 组件库（需要宿主提供 React/Vue）
Babel/ESLint 插件（需要宿主提供对应的核心包）
Webpack Loader/Plugin（需要宿主提供 Webpack）

npm v7+ 会默认自动安装 peerDependencies，之前版本只会发出警告。peerDependenciesMeta 可以将某些 peerDep 标记为 optional。

Q7：如何选择 npm / Yarn / pnpm？

回答思路：

没有绝对的最优选，取决于项目需求：

npm：最大优势是零配置，Node.js 自带，生态兼容性最好。适合小型项目、快速原型、对工具链简单性要求高的场景。
Yarn Berry（PnP）：适合追求极致安装速度和严格依赖管理的团队，特别是希望实现零安装的场景。但需要投入时间处理工具兼容性。
pnpm：综合最优选。磁盘节省显著、安装速度快、非扁平化结构解决幽灵依赖、Monorepo 支持优秀（Catalogs 功能）。生态兼容性好，迁移成本低。大多数新项目和 Monorepo 推荐首选 pnpm。

追问： 从 npm 迁移到 pnpm 需要注意什么？

主要关注：① 幽灵依赖问题——项目中可能隐式依赖了未声明的包，迁移后会报 Module not found；② shamefully-hoist 作为过渡方案；③ .npmrc 配置迁移；④ CI/CD 脚本中的命令替换；⑤ lockfile 转换（pnpm import 可以从 package-lock.json 或 yarn.lock 导入）。

Q8：什么是依赖地狱？有哪些解决方案？

回答思路：

依赖地狱是指项目中多个依赖对同一个包要求不同版本，导致版本冲突难以调和。典型表现：A 依赖 C@1.x，B 依赖 C@2.x，而 C@1.x 和 C@2.x 互不兼容。

解决方案分层：

包管理器层面：npm 的 overrides、Yarn 的 resolutions、pnpm 的 pnpm.overrides 可以强制统一版本
设计层面：库作者应遵循 SemVer、使用 peerDependencies 减少重复安装、保持宽松的版本范围
工具层面：使用 npm ls <package> 或 pnpm why <package> 分析依赖链，找到冲突根源
极端情况：使用 patch-package 或 pnpm 的 pnpm patch 直接修改有问题的依赖

包管理器 ​

一、npm 基础与进阶 ​

1.1 npm 安装机制 ​

1.2 node_modules 结构演进 ​

npm v2：嵌套结构 ​

npm v3+：扁平化结构 ​

幽灵依赖问题 ​

npm v7+：改进 ​

1.3 package.json 核心字段详解 ​

依赖分类 ​

peerDependencies 深入理解 ​

其他重要字段 ​

1.4 package-lock.json 的作用与结构 ​

1.5 语义化版本（SemVer） ​

1.6 npm scripts 生命周期钩子 ​

二、Yarn ​

2.1 Yarn Classic（v1） ​

2.2 Yarn Berry（v2+） ​

PnP 原理 ​

零安装（Zero-Installs） ​

2.3 .yarnrc.yml 配置 ​

2.4 PnP 模式与 node_modules 模式对比 ​

三、pnpm ​

3.1 核心架构 ​

3.2 非扁平化的 node_modules 结构 ​

3.3 pnpm 安装流程 ​

3.4 .npmrc 配置 ​

3.5 pnpm Store 管理 ​

四、三大包管理器对比 ​

4.1 核心对比表 ​

4.2 安装速度对比 ​

4.3 磁盘占用对比 ​

4.4 Corepack ​

五、依赖管理进阶 ​

5.1 依赖提升（Hoisting）与幽灵依赖（Phantom Dependencies） ​

5.2 依赖地狱（Dependency Hell） ​

5.3 依赖锁定策略 ​

5.4 安全审计 ​

5.5 依赖更新 ​

npm-check-updates (ncu) ​

自动化依赖更新 ​

六、Monorepo 与包管理器 ​

6.1 Workspaces ​

6.2 pnpm Catalogs（v9.5+） ​

七、面试高频问题 ​

Q1：npm install 的完整流程是什么？ ​

Q2：pnpm 为什么比 npm/yarn 快且省空间？ ​

Q3：什么是幽灵依赖？如何解决？ ​

Q4：^1.2.3 和 ~1.2.3 有什么区别？^0.2.3 呢？ ​

Q5：Yarn PnP 的工作原理是什么？有什么优缺点？ ​

Q6：peerDependencies 是什么？什么场景下使用？ ​

Q7：如何选择 npm / Yarn / pnpm？ ​

Q8：什么是依赖地狱？有哪些解决方案？ ​

八、延伸阅读 ​

包管理器

一、npm 基础与进阶

1.1 npm 安装机制

1.2 node_modules 结构演进

npm v2：嵌套结构

npm v3+：扁平化结构

幽灵依赖问题

npm v7+：改进

1.3 package.json 核心字段详解

依赖分类

peerDependencies 深入理解

其他重要字段

1.4 package-lock.json 的作用与结构

1.5 语义化版本（SemVer）

1.6 npm scripts 生命周期钩子

二、Yarn

2.1 Yarn Classic（v1）

2.2 Yarn Berry（v2+）

PnP 原理

零安装（Zero-Installs）

2.3 .yarnrc.yml 配置

2.4 PnP 模式与 node_modules 模式对比

三、pnpm

3.1 核心架构

3.2 非扁平化的 node_modules 结构

3.3 pnpm 安装流程

3.4 .npmrc 配置

3.5 pnpm Store 管理

四、三大包管理器对比

4.1 核心对比表

4.2 安装速度对比

4.3 磁盘占用对比

4.4 Corepack

五、依赖管理进阶

5.1 依赖提升（Hoisting）与幽灵依赖（Phantom Dependencies）

5.2 依赖地狱（Dependency Hell）

5.3 依赖锁定策略

5.4 安全审计

5.5 依赖更新

npm-check-updates (ncu)

自动化依赖更新

六、Monorepo 与包管理器

6.1 Workspaces

6.2 pnpm Catalogs（v9.5+）

七、面试高频问题

Q1：npm install 的完整流程是什么？

Q2：pnpm 为什么比 npm/yarn 快且省空间？

Q3：什么是幽灵依赖？如何解决？

Q4：^1.2.3 和 ~1.2.3 有什么区别？^0.2.3 呢？

Q5：Yarn PnP 的工作原理是什么？有什么优缺点？

Q6：peerDependencies 是什么？什么场景下使用？

Q7：如何选择 npm / Yarn / pnpm？

Q8：什么是依赖地狱？有哪些解决方案？

八、延伸阅读