为什么 npm install 会重写 package-lock.json
npm install 重写 package-lock.json 可能是正常同步行为，仍需检查差异：同步 package.json 变更、重新解析不一致的依赖树、执行安全修复或解决锁文件冲突时都会更新锁文件。想严格按锁文件安装，用 npm ci。
这可能是正常同步行为，但也需要检查具体差异，不能排除 npm 版本问题或解析缺陷。 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 影响；这不意味着每次跨平台都必须修改锁文件，异常差异需核对 npm 版本和解析问题。
普通 npm install 的审计报告不等于自动修复；npm audit fix 是会修改依赖的显式操作。
这为什么是设计如此
锁文件存在的意义是"固定依赖版本，提高安装的可复现性（平台可选依赖仍可能不同）"。当 package.json（意图）和锁文件（快照）出现分歧时，npm install 选择相信 package.json 并重写锁文件来对齐——语义上以开发者声明为准。
不想让它变：用 npm ci
npm ci
- npm ci 的安装解析流程不重写 package-lock.json，但生命周期脚本仍可能修改项目文件；
- 锁文件与 package.json 不一致时直接报错（而不是默默更新）；
- 先清理已有 node_modules 再安装；速度取决于缓存、网络和项目，不能笼统说一定更慢。
使用 npm 且有有效锁文件的 CI/CD 和生产构建通常用 npm ci，本地开发才用 npm install。
生成锁文件时影响依赖树的参数（例如 legacy-peer-deps）应与 CI 保持一致。项目根锁文件与 node_modules/.package-lock.json 隐藏锁文件用途不同，不能混为一谈。
常见问题（FAQ）
Q：package-lock.json 应该提交到 git 吗？
应用项目通常应提交。它是团队与部署环境依赖版本一致的重要依据；发布到 npm 的库不会靠自身 package-lock.json 锁定消费者依赖树。锁文件的变化应该像代码变更一样经过 review。
Q：团队协作时锁文件老冲突怎么办？
约定：只有专门升级依赖的 PR 才动锁文件；冲突后先确认 package.json 的预期变更，使用团队统一的 npm 版本重新解析并检查差异，再运行测试；不要为消除冲突直接删除锁文件导致无意升级。
Q：换 npm 大版本后锁文件全变了正常吗？
可能正常——lockfileVersion 升级可带来大幅格式变化，但也应区分格式迁移和实际依赖版本变化，不能一概忽略。建议团队统一 npm 版本（在构建环境和开发工具配置中固定，并在 CI 检查实际版本）。
