版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
主版本号：当你做了不兼容的 API 修改，
次版本号：当你做了向下兼容的功能性新增，
修订号：当你做了向下兼容的问题修正。
~：只升级修订号
^：升级次版本号和修订号
*：升级到最新版本
先行版本号及版本编译元数据可以加到“主版本号.次版本号.修订号”的后面，作为延伸
1. npm install sax@0.2.5 //install version 0.2.5
2. npm install sax@0.2.x //install the latest release of the 0.2 branch
3. npm install sax@"<0.3" //install the latest version before 0.3
4. npm install sax@">=0.1.0 <0.3.1"
"figlet": "*": 任意版本（>=0.0.0）
"react": "16.x": 匹配主要版本（>=16.0.0 <17.0.0）
"react": "16.3.x": 匹配主要版本和次要版本（>=16.3.0 <16.4.0）
NPM global vs local
一个模块可以包含一个或者多个可执行文件，
如果全局安装会使用默认的安装目录，npm将可执行文件安装在/usr/local/bin下。这个路径通常会同时添加在包含在PATH里；
如果局部安装一个包，npm会将所有的可执行文件安装在./node_modules/.bin目录下；
内部版本(alpha): 公测版本(beta): 正式版本的候选版本rc: 即 Release candiate
发布版本
在修改 npm 包某些功能后通常需要发布一个新的版本，我们通常的做法是直接去修改 package.json 到指定版本。如果操作失误，很容易造成版本号混乱，我们可以借助符合 Semver 规范的命令来完成这一操作： npm version patch : 升级修订版本号 npm version minor : 升级次版本号 npm version major : 升级主版本号
锁定依赖版本
lock文件
实际开发中，经常会因为各种依赖不一致而产生奇怪的问题，或者在某些场景下，我们不希望依赖被更新，建议在开发中使用 package-lock.json。 锁定依赖版本意味着在我们不手动执行更新的情况下，每次安装依赖都会安装固定版本。保证整个团队使用版本号一致的依赖。 每次安装固定版本，无需计算依赖版本范围，大部分场景下能大大加速依赖安装时间。 使用 package-lock.json 要确保npm的版本在5.6以上，因为在5.0 - 5.6中间，对 package-lock.json的处理逻辑进行过几次更新，5.6版本后处理逻辑逐渐稳定。
定期更新依赖
我们的目的是保证团队中使用的依赖一致或者稳定，而不是永远不去更新这些依赖。实际开发场景下，我们虽然不需要每次都去安装新的版本，仍然需要定时去升级依赖版本，来让我们享受依赖包升级带来的问题修复、性能提升、新特性更新。 使用 npm outdated 可以帮助我们列出有哪些还没有升级到最新版本的依赖： 黄色表示不符合我们指定的语意化版本范围 - 不需要升级 红色表示符合指定的语意化版本范围 - 需要升级 执行 npm update 会升级所有的红色依赖。
安装时最好使用~
全局设置 npm config set save-prefix ‘~’,默认是’^’; 0.1.11=>0.1.16:^0.1.11不会自动升级，比较中间版本号，没有变动，不会升级； 0.1.11=>0.1.16:~0.1.11会自动升级，比较最后一位版本号，有变动，升级；