当面试官问你
node的时候，更多引导面试官用node做前端工程化，去引导到webpack、npm、打包工具上面去说说自己的想法，不要引导到自己会后端，后台不是会一点node语法就能写的
# 1 package.json版本号规则
⚡ 30 秒速记
major.minor.patch：不兼容改动升major，兼容的新功能升minor，兼容的修复升patch^1.2.3=>=1.2.3 <2.0.0；~1.2.3=>=1.2.3 <1.3.00.x是特例：^0.2.3只到0.2.x，^0.0.3干脆只匹配0.0.3- 精确版本最稳但收不到补丁；
*/latest别用 - 真正决定装哪个版本的是锁文件，
^/~只在没锁文件或重新解析时才起作用
版本号是 major.minor.patch，前缀 ^ 和 ~ 决定允许自动升级到哪一位。 ^1.2.3 锁住主版本，1.x 里最新的都能装；~1.2.3 只接受 1.2.x 的补丁。容易被问倒的是 0.x：主版本是 0 的包被当成不稳定期，^0.2.3 只到 0.2.x，^0.0.3 就只认 0.0.3。不过实际装哪个版本，看的是 package-lock.json，范围只是告诉包管理器「重新解析时最多能接受到哪」。
major.minor.patch
- 主版本号.次版本号.修补版本号(
major.minor.patch) major：新的架构调整，不兼容老版本minor：新增功能，兼容老版本patch：修复bug，兼容老版本
~和^的区别
~会匹配最近的小版本依赖包，比如~1.2.3会匹配所有1.2.x版本，但是不包括1.3.0^会匹配最新的大版本依赖包，比如^1.2.3会匹配所有1.x.x的包，包括1.3.0，但是不包括2.0.0*安装最新版本的依赖包，比如*1.2.3会匹配x.x.x
那么该如何选择呢？当然你可以指定特定的版本号，直接写
1.2.3，前面什么前缀都没有，这样固然没问题，但是如果依赖包发布新版本修复了一些小bug，那么需要手动修改package.json文件；~和^则可以解决这个问题
- 但是需要注意
^版本更新可能比较大，会造成项目代码错误，所以 建议使用~来标记版本号，这样可以保证项目不会出现大的问题，也能保证包中的小bug可以得到修复。- 版本号写
*，这意味着安装最新版本的依赖包，但缺点同上，可能会造成版本不兼容，慎用
我们举个例子：
- 假设我们中安装了
vue, 当我们运行安装npm install vue -save的时候，在项目中的package.json的vue版本是vue: ^3.0.0, 我们电脑安装的vue版本就是3.0.0版本，我们把项目代码提交后，过了一段时间，vue发布了新版本3.0.1，这时新来一个同事，从新git clone克隆项目，执行npm install安装的时候，在他电脑的vue版本就是3.0.1了，因为^只是锁了主要版本，这样我们电脑中的vue版本就会不一样，从理论上讲（大家都遵循语义版本控制的话），它们应该仍然是兼容的，但也许bugfix会影响我们正在使用的功能，而且当使用vue版本3.0.0和3.0.1运行时，我们的应用程序会产生不同的结果。- 大家思考思考，这样的话，不同人电脑安装的依赖版项目，是不是都有可能不一样，就会导致每个人电脑运行的应用程序产生不同的结果。就会存在bug的隐患。
- 这时也许有同学想到，那么我们在package.json上面锁死依赖包的版本号不就可以了? 直接写
vue: 3.0.0锁死，这样大家安装vue的版本都是3.0.0版本了。- 这个想法固然是不错的，但是你只能控制你自己的项目锁死版本号，那你项目中依赖包的依赖包呢？你怎么控制限制别人锁死版本号呢？
- 为了解决这个不同人电脑安装的所有依赖版本都是一致的，确保项目代码在安装所执行的运行结果都一样，这时
package-lock.json就应运而生了
