前言
本篇文章写于第二次紧急处理因为yarn.lock被更新导致的线上线下代码行为不一致的问题之后。
lock文件有什么用
前端项目中一般都会有一个lock文件，它可能是yarn.lock、package.lock、pnpm-lock.yaml，当然也有可能同时存在多个（请不要这样）！不过它们主要的目的都是为了准确的记录我们引入的第三库之间的版本依赖关系。在我们安装依赖的时候(推荐ni)，相应的包管理器会根据当前项目中存在的lock文件安装对应版本的依赖。
与package.json的关系
如果说版本控制，我们应该第一时间留意的就是package.json，这应该是每一个开发者查看、添加第三方库以及指定其版本的地方。既然如此，那为什么还要用lock文件来管理版本依赖呢？
原因是在我们往package.json添加第三方库的时候，我们往往会在版本上添加前缀～、^、*符号，这些符号代表着匹配不同的版本。例如一个版本号通常有3.2.25组成，它们分别是:主版本号、次版本号、修订版本号。而以上不同的前缀代表着会匹配不同版本号的最新版本，比如当我们添加前缀～的时候，如果当前版本存在3.2.27，那么我们可能安装的是3.2.27，而不是标明的3.2.25。
- ～：匹配最新的修订版本
- ^ ：匹配最新的次版本、修订版本
- * ：匹配最新版本
而之所以我们要使用这种前缀(经常会使用~、^)来增加版本的不确定性，是因为次版本号、修订版本号一般代表着我们依赖的第三方库的一些非破坏更新：Bug修复、新特性等。这就是为什么我们还需要lock文件的原因：希望我们能及时获取到不同第三方库的bug修复以及新特性，并能为所有参与进来的开发者保持相同的依赖。
为什么会出问题？
导致出问题的行为可能有很多种，但是它们的来源都很单一，即我们本地的node_modules和部署时的node_modules不一致。这是因为部署时每次都会执行依赖安装，而我们本地的node_modules不是根据最新的lock文件来安装的。让我们来举几个可能的行为：
- 内部使用的包管理工具不一致，从而导致有多个lock文件
- 伙伴只是更新了某个依赖库的版本，不是增删，从而引起了lock文件的更新。提交后由于我们没有相关依赖的缺失就没有想到执行ni（依赖安装）导致的不一致
- 我们更新了相关依赖但没有提交lock文件
- 伙伴添加了库但没有提交lock文件，然后我们安装后也不提交lock文件
总结
- 不要用不同的包管理器
- 要常常执行一下依赖安装
- 不要不提交lock文件的更改
- 不要不提交lock文件的更改
- lock发生合并冲突时，可以再次执行依赖安装的命令来让包管理器处理
