npm shrinkwrap 通过生成并提交 npm-shrinkwrap.json 文件严格锁定整个依赖树（含嵌套子依赖），确保各环境安装完全一致的版本；需先清理 node_modules 并重装后再执行，更新依赖时必须重新 shrinkwrap 并提交文件。
用 npm shrinkwrap 严格锁定生产依赖树，核心是生成并提交 npm-shrinkwrap.json 文件，让所有环境安装完全一致的依赖版本（含嵌套子依赖），避免因 npm 版本差异或 registry 变动导致的“在我机器上能跑”的问题。
执行 shrinkwrap 并生成锁定文件
在项目根目录运行：
npm shrinkwrap
这会根据当前 node_modules 中实际安装的依赖结构，递归遍历所有层级，生成 npm-shrinkwrap.json。该文件包含每个包的精确版本、完整性哈希（integrity）、下载地址（resolved）和依赖关系树。
- 确保
node_modules是干净且可复现的——建议先删掉它，再用npm install重装一遍，再 shrinkwrap - 如果项目已有
package-lock.json（npm ≥5 默认生成），shrinkwrap仍会覆盖生成自己的文件，二者不共存；npm 会优先尊重npm-shrinkwrap.json - 生成后务必
git add npm-shrinkwrap.json并提交——这是锁定生效的前提
理解 shrinkwrap 的作用范围
npm shrinkwrap 锁定的是整个依赖树，包括 dependencies、devDependencies 和它们所有间接依赖，但默认不锁定顶层 devDependencies 的安装行为（除非你明确在生产环境也装它们）。
立即学习“Java免费学习笔记（深入）”；
- 部署时用
npm install --production，npm 仍只装dependencies及其子依赖，但所有版本都严格按npm-shrinkwrap.json指定 - 即使某个包在
package.json中写的是^1.2.0，shrinkwrap 也会强制固定为实际安装的1.2.3（含完整路径和哈希） - 它比
package-lock.json更“强硬”：即使你本地改了package.json，只要不重新 run shrinkwrap，CI 或服务器仍按旧锁文件装
更新依赖时必须重新 shrinkwrap
不能只改 package.json 就以为依赖更新了。任何版本变更（升级、降级、增删包）后，必须手动重新生成锁文件：
- 先修改
package.json，然后rm -rf node_modules && npm install - 确认安装无误、测试通过后，再执行
npm shrinkwrap - 检查生成的
npm-shrinkwrap.json是否包含预期变更（比如搜索包名，看 version 和 integrity 是否更新） - 提交新文件——否则其他环境不会感知变化
注意兼容性与现代替代方案
npm shrinkwrap 在 npm v6 中仍可用，但自 npm v7 起已被官方标记为遗留命令；npm 推荐统一使用 package-lock.json + lockfileVersion: 2 或更高，并配合 npm ci 实现同等效果。
- 如果你用的是较新 npm（≥7）且无特殊需求，优先用
npm ci（读取package-lock.json精确安装，跳过 package.json 解析） - 若团队或 CI 明确要求兼容老 npm（如 v4/v5），或需对
devDependencies也做强约束（比如构建工具链），shrinkwrap 仍是可靠选择 - 注意：shrinkwrap 不支持 workspace，monorepo 场景请改用
npm workspaces配合 lockfile
