4、yarn依赖回滚：yarn.lock文件详解、yarn install --frozen-lockfile、yarn upgrade与回滚策略

说实话，很多团队把 yarn.lock 当成一个「自动生成」的文件，提交了就完事。但你真的理解它锁住了什么吗？

yarn.lock 不是锁住版本号，而是锁住依赖树的完整结构。它记录了每个包的具体版本、安装来源（registry）、以及最重要的——依赖的依赖。

举个例子，你装了 react@18.2.0，它依赖 scheduler。yarn.lock 会记录下 scheduler 的具体版本，以及 react 和 scheduler 之间的对应关系。下次任何人执行 yarn install，都会得到完全相同的 node_modules。

我个人习惯，每次代码审查时都会扫一眼 yarn.lock 的 diff。如果发现某个包的 resolved 字段变了，或者 integrity 校验值变了，那就要警惕了——可能有人改了 lock 文件但没改 package.json。

  核心要点： yarn.lock 是依赖树的「快照」，不是版本号的「清单」。

这个命令，说白了就是「严格按照 lock 文件安装，不准改」。我在 CI 流水线里一定会用这个参数。

为什么？因为默认的 yarn install 如果发现 package.json 和 yarn.lock 不一致，它会自动更新 lock 文件。这在本地开发时没问题，但在 CI 环境里，这会导致构建结果不可复现。

# 推荐在 CI 中使用
yarn install --frozen-lockfile

# 如果 lock 文件与 package.json 不一致，会直接报错退出
# 而不是默默更新 lock 文件

我曾经遇到过一个坑：开发者在本地改了 package.json 但忘了执行 yarn install 更新 lock 文件，结果 CI 构建时自动生成了新的 lock 文件，导致测试环境和生产环境的依赖不一致。用了 --frozen-lockfile 后，这种问题直接变成构建失败，反而更容易排查。

注意： --frozen-lockfile 不会检查 node_modules 是否过期。如果你需要确保 node_modules 和 lock 文件完全一致，可以配合 --check-files 使用。

yarn upgrade 这个命令，我建议谨慎使用。它不像 npm update 那样保守，而是会尝试将包升级到符合 semver 范围的最新版本，并更新 yarn.lock。

# 升级所有依赖到最新版本（符合 semver 范围）
yarn upgrade

# 升级单个包
yarn upgrade lodash

# 升级到指定版本
yarn upgrade lodash@4.17.21

这里有个容易踩的坑：yarn upgrade 默认会升级所有符合条件的包。如果你只想升级某个包，一定要指定包名。否则，你可能会不小心升级了一堆间接依赖，导致意想不到的问题。

我记得有一次，团队里有人执行了 yarn upgrade 没加参数，结果把 babel 相关的十几个包都升级了。虽然 semver 范围都允许，但不同版本的 babel 插件之间出现了兼容性问题，花了半天才定位到原因。

回滚依赖，本质上就是「让 lock 文件回到某个已知的稳定状态」。我总结了三种常用策略：

策略	适用场景	操作方式
Git 回滚	整个项目回退到某个版本	git checkout <commit> -- yarn.lock
版本锁定	只回滚某个包	修改 package.json，重新 yarn install
缓存清理	怀疑缓存导致的问题	yarn cache clean + yarn install

策略一：Git 回滚 lock 文件

这是最直接的方式。如果你知道某个 commit 的依赖是稳定的，可以直接把那个版本的 yarn.lock 拿回来。

# 从某个 commit 恢复 lock 文件
git checkout abc1234 -- yarn.lock

# 然后重新安装
yarn install --frozen-lockfile

策略二：版本锁定 + 重新安装

如果只是某个包出了问题，不需要回滚整个项目。直接在 package.json 里指定具体版本，然后重新生成 lock 文件。

// package.json
{
  "dependencies": {
    "lodash": "4.17.21"  // 去掉 ^ 或 ~，锁定精确版本
  }
}

# 重新安装
rm -rf node_modules
yarn install

策略三：利用 yarn 的 resolutions 字段

这个技巧我很少见人用，但真的很实用。resolutions 可以强制指定某个间接依赖的版本，即使它的父依赖声明了不同的版本范围。

// package.json
{
  "resolutions": {
    "lodash": "4.17.21"
  }
}

这样做的好处是，你不需要修改任何直接依赖的版本声明，就能控制间接依赖的版本。我曾在修复一个安全漏洞时用过这个技巧——某个深层依赖有漏洞，但它的父依赖还没更新，用 resolutions 直接覆盖掉。

小技巧： 回滚后一定要执行 yarn install --frozen-lockfile 验证一下，确保 lock 文件和 package.json 一致。我每次回滚后都会跑一遍完整的测试套件，确认没有引入回归问题。

下面这张图，是我对 yarn 依赖回滚整个知识体系的梳理。你可以把它当作一个快速参考。

嗯，这张图基本把 yarn 依赖管理的核心脉络理清了。你想想看，从 lock 文件的结构，到安装命令的选择，再到升级回滚的策略，其实都围绕着一个核心原则：lock 文件是依赖树的唯一真相。

我在实际工作中，会把 yarn.lock 当作「代码」一样对待。代码审查时要看它，CI 构建时要校验它，回滚时要恢复它。只有这样，才能确保团队里每个人的开发环境、测试环境和生产环境完全一致。

一句话总结： 依赖回滚不是技术问题，而是流程问题。把 lock 文件管好了，回滚就是 git checkout 的事。

可可精品资料库