1.为什么要使用npm run dev,而不是运行package.json的scripts选项下的命令？
答：运行npm run * 命令实际上是先去找 node_modules下的.bin文件包，去找相关命令执行的，直接运行相当于你去你所在的操作系统的全局环境运行，如果你的npm包不是通过 -g 命令安装的，实际上你是没有在全局添加环境变量让你直接调用的。那node_modules中的.bin包的命令是什么时候添加的呢？是你在npm install的时候，你所安装的依赖包中的package.json中有个bin选项，这个bin选项的值会添加的node_modules中的bin下面。
参考链接：juejin.cn/post/707892…
2.package-lock.json文件的作用？
我一开始以为package.json的所有依赖项都标注的就是个版本号，然后每个项目按照版本号下载就完事了，就保证了大家依赖的第三方文件的统一，实际并不是（这种想法存在一个明显的问题就是，如果你依赖的第三方库存在一个bug，人家库作者已经更新了，但你这边由于是写死的版本号，那你不就更新不到最新的项目代码了吗），你看package.json的每个依赖版本号前面都是有特殊符号的（^，~等，各自的含义这里就不列举了），反正最后的意思就是这个package.json只能保证你最大的那个版本给你锁死（也就是小数点最前面的一位），其他的小版本根据特殊符号的不同更新的机制也不同，一般都是保持最新，所以这就对第三方库的维护者有个要求，他们发布的版本要严格按照所谓的semver 版本表示法，
1.主版本号,一些不兼容的breaking change；
2.次版本号，能向下兼容，在不影响低版本的试用下可以新增可弃用一些api，但要确保向下兼容。
3.补丁版本号，
一些向下兼容的修正，一般都是对于一些缺陷的修复 当发布新版本的时候，可不能随心所欲地增加数字，一定要遵循上述的规则，这是作为一个合格的项目所必备的基本条件。
但有些库作者不守规矩，可能在2、3的小版本更新中引入了breaking change，这样我们在npm install的时候就可能会发生自己的代码有问题，但同事的代码没问题（这种时候一般都会让同事把他的node_modules打个压缩包发给自己哈哈哈），就比较恶心，所以npm 在5版本之后推出了package-lock.json文件，这个就是为了锁死你当前执行npm install的时候你正在使用的所有第三方以来包的精确版本，这个文件是需要上传到git管理系统的，这样以后大家的node_modules包就都统一了，你可能会问如果某个第三方包存在bug，需要更新怎么办，在以前可能就是直接改package.json里面的版本，然后再npm install了，但是5版本后就不支持这样做了，因为版本已经锁定在package-lock.json里了，所以我们只能npm install xxx@x.x.x 这样去更新我们的依赖，然后package-lock.json也能随之更新。
db.collection('c_motto')
.where({
date: db.command.exists(true)
})
.update({
data:{
isSpecialMorning:false,
isSpecialNight:false,
isSpecial:db.command.remove()
}
})
参考链接：juejin.cn/post/705381…
www.cnblogs.com/cangqinglan…
