之前因为项目需求，经常使用cnpm i来下载依赖，后来有一次在debug的过程中发现用cnpm下载安装依赖是不会锁版本的，特此就这个问题在这里做个详细记录。
首先了解下npm包管理及依赖版本管理的原理。这些都是通过package.json文件实现的 当你使用npm安装一个包(并保存它)或者更新一个包的时候，package.json里就自动添加了一条信息，包括包名和其版本。npm默认安装最新版本，然后在其版本号之前添加一个符号。比如1.2.12，它表明最低应使用1.2.12版本。并且在这之上，拥有相同大版本号的任何版本都是OK的。毕竟小版本和bugfix版本不会对使用造成任何影响，所以用任何相同大版本的更高级版本都很安全。
符号^：表示主版本固定的情况下，可更新最新版。例如：vuex: “^3.1.3”，3.1.3及其以上的3.x.x都是满足的。
符号~：表示次版本固定的情况下，可更新最新版。如：vuex: “~3.1.3”，3.1.3及其以上的3.1.x都是满足的。
无符号：无符号表示固定版本号，例如：vuex: “3.1.3”，此时一定是安装3.1.3版本。
没有版本锁定的情况下，在执行每次npm i的时候，对应的版本前都有个^符号。也就是未固定版本的依赖如果有了次版本更新或者修订版本更新，会自动安装对应的最新版。 在这种情况下，你再次install时安装的包的版本可能与前次不一样，具体的，你可以到package-lock.json中查看实际的包版本。 例如：A新建了一个项目，生成了上面这份package.json文件，但A安装依赖的时间比较早，此时packageA的最新版本是2.1.0，该版本与代码兼容，没有出现bug。后来B克隆了A的项目，在安装依赖时packageA的最新版本是2.2.0，那么根据语义npm会去安装2.2.0的版本，但2.2.0版本的API可能发生了改动，导致代码出现bug。
这就是package.json会带来的问题，同一份package.json在不同的时间和环境下安装会产生不同的结果。
理论上这个问题是不应该出现的，因为npm作为开源世界的一部分，也遵循一个发布原则：相同大版本号下的新版本应该兼容旧版本。即2.1.0升级到2.2.0时API不应该发生变化。但很多开源库的开发者并没有严格遵守这个发布原则，导致了上面的这个问题。
为了在不同的环境下生成相同的node_modules，引入版本依赖锁定就尤为必要了。
首先要说的是，很多同学可能习惯使用cnpm，因为安装速度确实比npm快不少，但在版本依赖锁定方案中，最基础的一条就是：不要使用cnpm，因为cnpm，是不支持依赖版本锁定的。
也即是说，无论你的项目中有package-lock.json、npm-shrinkwrap.json还是yarn-lock.json文件，执行cnpm i安装依赖的时候他们都只是摆设，都只会根据package.json文件进行安装。所以通过cnpm安装依赖是不能避免上面问题的。而且有很多网友反馈cnpm会有依赖包丢失的问题。
但是使用npm避不开的一个问题就是安装速度，实在太慢了。这里我们可以通过手动更换npm源和nrm的方式实现使用npm命令的同时，依然享受cnpm的安装速度。
- 手动更换npm源
设置npm源： npm config set registry [url]
查看确认: npm config get registry
- 使用nrm
安装nrm npm i nrm -g
查看可选的源 nrm ls
有的运行命令时，会报错：
需要修改下报错的地方，点击打开C:\Users\liang\AppData\Roaming\npm\node_modules\nrm\cli.js:17:20
修改：
//const NRMRC = path.join(process.env.HOME, '.nrmrc'); (删除)
const NRMRC = path.join(process.env[(process.platform == 'win32') ? 'USERPROFILE' : 'HOME'], '.nrmrc');
再运行nrm ls，显示出列表，报错解决
在列出的列表中，带*的是当前使用的源，上面的输出表明当前源是官方源。
切换到某个源：nrm use xx
例如切换到淘宝源：nrm use taobao
增加源（添加企业内部的私有源或者其他源）： nrm add [registryName] [url]
删除源： nrm del <registryName>
测试某个源的相应时间： nrm test taobao
作者：咸鱼翻身翻两次
链接：https://juejin.cn/post/6960928446826741796
来源：稀土掘金
