JavaScript依赖管理核心是装对、用对、更新稳：npm 5+默认写入dependencies，--save冗余；package-lock.json必须提交并禁手动编辑；peerDependencies需显式安装；npm update不跨主版本，大版本升级须手动改package.json。
JavaScript 项目里依赖包管不好，不是 node_modules 膨胀到 500MB，就是上线后报 Cannot find module 'xxx' —— 根本不是“装不装得上”的问题，而是“装对没、用对没、更新稳不稳”的问题。
npm install 时加不加 --save 参数？现在根本不用管
从 npm 5 开始（对应 Node.js 8.0+），npm install 默认就写入 dependencies，npm install 才写入 devDependencies。老教程里反复强调的 --save 已成冗余操作。
- 装运行时依赖：直接
npm install lodash - 装构建/测试依赖：明确加
--save-dev，比如npm install jest --save-dev - 全局安装（如
eslintCLI）≠ 项目依赖，别用-g替代本地安装
package-lock.json 不是可选文件，删了它等于埋雷
package-lock.json 锁定的是**确切版本号 + 完整依赖树 + tarball 哈希值**，不是“建议版本”。没有它，不同机器 npm install 可能拉下不同子依赖，引发“在我机器上好好的”类故障。
- 必须提交到 Git —— 即使你用 pnpm 或 yarn，它们也各自生成等效锁文件（
pnpm-lock.yaml/yarn.lock） - 不要手动编辑
package-lock.json；想更新依赖，用npm update或重装 - CI 环境务必执行
npm ci（而非npm install），它跳过package.json解析，只按锁文件还原，更快更确定
peerDependencies 不是让你忽略的警告，是集成契约
当你装一个库（比如 react-router-dom）报 peer dep missing，它不是在“提醒你”，而是在声明：“我只承诺兼容 react@^18.0.0，你用了 17 或 19，出问题我不负责。”
立即学习“Java免费学习笔记（深入）”；
- 这类依赖必须由你自己显式安装，例如：
npm install react@18.2.0 - 常见于插件类包（
eslint-plugin-react、@vue/compiler-sfc），它们不打包宿主环境，只扩展其能力 - 用
npm ls查看是否满足，比如npm ls react会显示实际解析到哪个版本
升级依赖不能只靠 npm outdated + npm update
npm update 只升到 package.json 中允许的最新兼容版本（比如 "lodash": "^4.17.0" 最多升到 4.17.21，但不会跨到 4.18.0），而大版本升级（如 4.x → 5.x）必须手动改 package.json 并重装。
- 先查现状：
npm outdated看哪些包有新版本、是否符合 semver 范围 - 小版本/补丁升级：
npm update安全，通常无破坏性 - 主版本升级：必须读该包的
CHANGELOG.md或迁移指南，再执行npm install@major-version - 推荐用
npx npm-check-updates（简称ncu）批量更新package.json中的版本号字段，再npm install实际安装
依赖管理最常被忽视的，是“谁在用这个包”—— 一个 console.log 都可能通过某个深埋三层的 transitive dependency 引入 2MB 的 polyfill。真要精简，得靠 npm ls 和 depcheck 这类工具挖，而不是凭感觉删 node_modules 里的文件夹。
