掌握 npm 依赖管理的关键在于理解“版本声明—安装行为—目录结构—锁定机制”四层联动逻辑：^、~、无符号等版本符号决定升级边界；dependencies、devdependencies、peerdependencies 三类依赖用途各异；node_modules 通过扁平化与提升（hoist）优化结构；package-lock.json 是保障环境一致性的唯一依据。
掌握 npm 依赖管理，关键不在死记命令，而在理解“版本声明—安装行为—目录结构—锁定机制”这四层联动逻辑。它不是孤立工具，而是 Node.js 工程化落地的中枢神经。
看懂 package.json 里的版本符号
版本号前的符号决定升级边界，直接影响后续 install 行为：
- ^1.2.3：允许升级到 兼容的最新次版本，即 1.x.x（不跨主版本），如自动升到 1.9.0；但 2.0.0 不会装
- ~1.2.3：只允许升级 补丁版本，即 1.2.x，如升到 1.2.9；1.3.0 不会装
- 1.2.3（无符号）：严格锁定，只装这个精确版本
- * 或 latest：危险操作，指向 registry 中标记为 latest 的版本，易引发不可控更新
分清三类依赖的实际用途
字段写在哪，决定了包何时被加载、是否被打包、以及 CI 环境如何处理：
- dependencies：运行时必需，比如 express、lodash。生产环境必须存在，会被 webpack/rollup 打入 bundle（若未 external）
-
devDependencies：仅开发阶段需要，比如 jest、vite、eslint。npm install 默认不跳过它，但
npm ci --only=production或NODE_ENV=production npm install会忽略它 - peerDependencies：声明“我期望宿主项目提供什么”。常见于插件（如 eslint-plugin-react），它不自动安装，只报 warning；宿主项目需自己装对应版本，否则运行时可能出错
理解 node_modules 是怎么“扁平化”的
npm 3+ 不再嵌套安装，而是把能共存的依赖提到根 node_modules 下：
- 如果 pkg-a 和 pkg-b 都依赖 lodash@4.17.21 → 只装一份在根 node_modules/lodash
- 如果 pkg-a 依赖 lodash@4.17.21，pkg-b 依赖 lodash@4.17.15 → 后者被 hoist 失败，留在 pkg-b/node_modules/lodash
- 隐患是“幽灵依赖”：你代码里直接 require('lodash') 能运行，但 package.json 没声明，换环境或重装就崩——这就是为什么不能靠提升侥幸
package-lock.json 是构建可信的唯一依据
它不是可选文件，而是 npm install 的“执行快照”：
- 记录每个包的完整 resolved URL、integrity hash（防篡改）、依赖树层级、是否为可选依赖等
-
npm install优先按 lock 文件还原，而非 package.json —— 这是保证多人、CI、部署环境一致的核心 -
npm ci更严格：删 node_modules + 忽略 package.json，只信 lock 文件，适合自动化流水线 - 切勿手动编辑 lock 文件；更新依赖后，它会自动重生成
不复杂但容易忽略
