为什么 npm install 会重写 package-lock.json
npm install 重写 package-lock.json 是正常行为：同步 package.json 变更、重新解析不一致的依赖树、执行安全修复或解决锁文件冲突时都会更新锁文件。想严格按锁文件安装，用 npm ci。
这是正常现象，不是 bug。 package-lock.json 的职责是精确记录整个依赖树的实际安装版本，而 npm install 在以下情况会重新解析并更新它：package.json 有变动、锁文件与 package.json 不一致、锁文件损坏或格式版本过旧、npm audit fix 修复漏洞后同步结果。
触发重写的常见场景
- package.json 变了：手动改了版本范围、增删依赖，npm install 会重新解析使两者一致；
- 升级依赖：
npm update或装了新包，锁文件记录新版本； - 锁文件版本升级：老 npm 生成的 lockfileVersion 1 会被新版 npm 升级为 2/3 格式；
- 审计修复：
npm audit fix替换有漏洞的包版本后写回锁文件； - 平台差异：可选依赖在不同 OS/CPU 上的解析结果不同，可能产生差异。
这为什么是设计如此
锁文件存在的意义是"固定依赖版本，提高安装的可复现性（平台可选依赖仍可能不同）"。当 package.json（意图）和锁文件（快照）出现分歧时，npm install 选择相信 package.json 并重写锁文件来对齐——语义上以开发者声明为准。
不想让它变：用 npm ci
npm ci
- 严格按锁文件安装，绝不修改 package-lock.json；
- 锁文件与 package.json 不一致时直接报错（而不是默默更新）；
- 先清理已有 node_modules 再安装；速度取决于缓存、网络和项目，不能笼统说一定更慢。
CI/CD 和生产构建一律用 npm ci，本地开发才用 npm install。
常见问题（FAQ）
Q：package-lock.json 应该提交到 git 吗？
必须提交。它是团队与部署环境依赖版本一致的重要依据。锁文件的变化应该像代码变更一样经过 review。
Q：团队协作时锁文件老冲突怎么办？
约定：只有专门升级依赖的 PR 才动锁文件；冲突后先确认 package.json 的预期变更，使用团队统一的 npm 版本重新解析并检查差异，再运行测试；不要为消除冲突直接删除锁文件导致无意升级。
Q：换 npm 大版本后锁文件全变了正常吗？
正常——lockfileVersion 升级（1→2→3）会整体重写格式。建议团队统一 npm 版本（在构建环境和开发工具配置中固定，并在 CI 检查实际版本）。
