共计 1612 个字符，预计需要花费 5 分钟才能阅读完成。
前言
从 Yarn 横空出世推出 lock 文件以来，已经两年多时间了，npm 也在 5.0 版本加入了类似的功能，lock 文件越来越被开发者们接收和认可。本篇文章想从前端视角探讨一下我们为什么需要 lock 文件，以及它的一些成本与风险，当然其中一些观点对于后端也是适用的。
为什么需要 lock 文件
之所以需要 lock 文件，我觉得主要有 4 个原因：
确保各环境依赖版本的一致性
软件开发一般有着好几个环境，通常包括本地开发环境、集成测试环境、预发布环境以及线上环境。各环境依赖版本不一致通常是 bug 的一大来源，大家可能碰到过“在我的电脑上是好的”这种问题，也许就是依赖版本不一致导致的。这种问题通常很难定位，因为你很难确定到底是自己的问题还是依赖的问题。这也是 Yarn 推出 lock 文件的初衷之一，使用了 lock 文件，你在排查问题时至少可以排除依赖版本不一致这个因素。
语义化版本并不绝对可靠
一些开发者不愿意使用 lock 文件，一个主要原因是他们希望基于语义化版本号让依赖自动升级，认为只要选择的依赖可靠，大版本不变化就可以放心升级。在绝大多数情况下这么做不会有问题，但是也有意外情况，比如：
React 在 v16.4.0 对 getDerivedStateFromProps 的调用时机进行了调整。React 在 v16.3.0 引入了这个 API，最初只有在父组件引起的重渲染过程中会被调用，v16.4.0 调整为在所有渲染过程中都会被调用。如果你在不知情的情况下（自动）把 React 从 v16.3.0 升级到了 v16.4.0，那么极端情况下你的应用就会出问题。
虽然只有在很极端的情况下你才会碰到类似问题，但是这种问题本来就是不怕一万就怕万一。
可控的升级依赖
现在通过 webpack 把依赖单独提取为一个 vendor.js 是个很常见的做法，因为依赖变更相对来说没那么频繁，再配合上强缓存，可以做到即使发布了新版本，用户也可以使用缓存的 vendor.js 而不必重新下载。通常我们的应用不止一个依赖，这些依赖肯定也不是同一时间发布更新，如果不使用 lock 文件让其自由更新，可能会导致 vendor.js 缓存失效多次（每个依赖更新都会导致缓存失效）。如果使用 lock 文件就可以积累一段时间，让多个依赖集中更新，甚至跳过一些小版本更新，从而提高 vendor.js 的缓存命中率。
安全问题
几个月前 ESLint 发生了一个安全事故，一个攻击者窃取了 ESLint 维护者的 npm 账户，并发布了恶意版本的 eslint-scope 和 eslint-config-eslint（都是更新的小版本），其中前者是 babel-eslint 和 webpack 的依赖。如果没有使用 lock 文件，那么你就极有可能中招，ESLint 事后也建议开发者使用 lock 文件来避免自动安装新版本。
成本
使用 lock 文件自然会增加一点项目的维护成本，因为依赖不会再自动升级，所以需要项目维护者每隔一段时间手动进行升级。另外如果两个人同时修改了依赖，解决 lock 文件的冲突也是一件很麻烦的事。
但是手动升级依赖也有一些额外的好处，至少你升级每个依赖时都要去看一下它的 change log，这样可以对每一次升级做到心中有数，这也有助于你掌握依赖的发展趋势。比如前文提到的 React 的例子，只要你在升级时看一眼它的 change log，就很容易避开可能出现的问题。
风险
我唯一能想到的风险就是依赖版本固化问题，如果你使用了 lock 文件又没有花时间跟精力去维护它，那么你的项目就很容易陷入依赖版本固化的问题。如果太久没有升级依赖，你当前使用的版本跟最新版差别太大，升级就会很困难，考虑到现实成本问题，可能就永远不会升级了。
但是如果不使用 lock 文件就能完全避免这个问题吗，我想也不一定。不使用 lock 文件最多也只能在同一个大版本范围内自动升级，如果依赖升级了大版本，你没有花时间去升级，也会碰到同样的问题。只是相对于不使用 lock 文件，问题暴露的晚一些而已。
