执行npm i为何不遵循package-lock.json安装新版本？如何阻止？

嘿，我来帮你把这个问题掰扯清楚——很多人一开始都以为package-lock.json是个“绝对锁死”的文件，但其实它的设计逻辑里留了一些灵活空间，导致你遇到的这种情况。

为啥会出现这种情况？ #

首先得纠正一个误解：package-lock.json不是100%强制锁死所有版本，它的核心作用是记录当前安装的依赖树状态，但在某些场景下，npm会自动更新依赖并修改lock文件，常见原因有这几个：

• package.json里的版本范围不是精确值：比如你写的是"axios": "^1.0.0"，^符号表示允许安装兼容的小版本更新（比如1.6.0）。当npm检测到有这样的版本可用，且没有冲突时，就会自动安装更高版本，同时更新lock文件。
• npm版本差异：不同npm版本对lock文件的处理逻辑不一样，比如npm 7+比npm 6更倾向于自动更新依赖来解决版本冲突，哪怕lock文件已经存在。
• 间接依赖的更新：如果你的某个依赖的依赖有安全补丁或者版本冲突，npm可能会自动调整这些间接依赖的版本，进而触发lock文件的更新。
• 安装新依赖时顺带更新：如果你执行的是npm install <新包>而不是纯npm i，npm会顺便更新现有依赖的兼容版本，同时修改lock文件。

怎么阻止这种情况发生？ #

想要严格按照package-lock.json的版本安装，有几个靠谱的方法：

• 用精确版本号写package.json：把所有依赖版本前面的^、~这些范围符号删掉，比如改成"lodash": "4.17.21"。这样npm会严格按照这个版本安装，不会自动更新。
• 用npm ci代替npm i：这是最推荐的方案！npm ci（CI是持续集成的意思）就是专门为“严格遵循lock文件”设计的——它会完全按照package-lock.json里的版本安装所有依赖，不会更新任何包，也不会修改lock文件。如果package.json和lock文件的版本不匹配，它还会直接报错，确保依赖完全一致。本地开发和CI环境都能用。
• 锁定npm版本：因为不同npm版本处理lock文件的逻辑有差异，你可以在项目根目录创建.nvmrc文件，指定项目用的npm版本（比如18.17.0），团队所有人都用同一个版本，避免因npm版本不同导致的lock文件变动。
• 可选：用npm shrinkwrap：npm shrinkwrap会生成npm-shrinkwrap.json文件，它的优先级比package-lock.json更高，行为更严格。不过现在大部分场景下package-lock已经足够，这个算是备选方案。

内容的提问来源于stack exchange，提问作者Peter Prographo