您运行 yarn install，并且您刚更新的依赖项仍然解析到旧的构建中。或者您的笔记本电脑安装正常，而CI突然在无害的锁文件更改后失败。或者Docker重建拖慢，尽管您正在“使用缓存”。
通常在这种情况下，人们会搜索 Yarn清除缓存 并粘贴他们找到的第一个命令。
有时这有效。有时这解决不了问题。原因很简单：Yarn的缓存行为取决于您正在运行的Yarn版本，以及Yarn V1和Berry（v2+）之间的区别。 Yarn Classic v1 和 Yarn Berry v2+ 足以改变正确的命令和正确的故障排查策略。
大多数指南只到这里就停了。 That’s 只是开始。 What matters 是缓存范围，项目是否使用本地缓存还是共享缓存，以及您真正的问题是否就是缓存本身。 在 CI 和 Docker 中，缓存策略不当往往会比陈旧的包存档带来更多痛苦。 yarn cache clean目录
您的构建已损坏，Yarn 缓存可能是原因
- 何时何时清除 Yarn 缓存
- 指向缓存问题的症状
- __CAPGO_KEEP_0__
- Yarn Berry v2+中的现代缓存管理
- CI/CD和Docker的Yarn缓存最佳实践
- 解决常见的Yarn缓存错误
- 关于清除Yarn缓存的常见问题
你的构建出错了，Yarn 缓存可能是原因
你可能遇到过这样的情况：你更新了一个包，pull 了最新的代码，重新运行 install 命令。命令执行完成，但应用程序仍然表现得像依赖项没有更新一样。然后有人建议清除缓存，你就开始怀疑这是否是一个真正的解决方案还是只是迷信
清除缓存确实可以解决问题，也可能只是一个干扰
缓存问题通常会以几个预测的方式出现。一个本地包不会更新。CI 拉取了不期望的内容。一个新 branch 的行为与主 branch 不同，尽管 lockfile 表示应该匹配。如果你已经在追踪更广泛的 pipeline 不稳定性，帮助你是将缓存调试与系统性的构建检查结合起来，例如在 修复 Capacitor CI/CD pipeline 构建失败的指南.
实践规则： 将 Yarn 清除缓存作为诊断工具，而不是维护习惯
Yarn 缓存模型在不同时间有所变化。在旧项目中，缓存是共享的。在新项目中，缓存清除可以是本地的、全局的，或者两者兼而有之，取决于命令参数。所以当同事说“只需清除 Yarn 缓存”，你应该问： which Yarn?
为什么缓存修复需要了解上下文？ 本机或 CI 运行器。 Yarn v1 或 Berry。 共享缓存或项目缓存。 一旦你了解了这些，命令就变得精确而不是盲目了。
何时何时清除 Yarn 缓存
清除 Yarn 缓存在某些特定故障模式下有意义。 当你需要移除陈旧的包裹艺术品、恢复从断点下载状态或故意擦除存储的包裹以便 Yarn 从头开始重建时，清除缓存最有用。
提示缓存问题的症状
有些情况是强烈的缓存候选者：
- 依赖项拒绝更新： 你改变了版本，或者重建了一个本地包，但安装仍然拉取一个旧的艺术品。
- 安装失败，感觉像状态相关： 一个机器正常，另一个不正常，重新运行相同的命令仍然重现相同的坏结果。
- 你需要回收本地磁盘空间： 在开发机器上比在短暂的CI环境中更重要.
其他情况看起来像缓存问题，但实际上并非如此。如果你的lockfile意外改变了，工作区设置不一致，或者Docker构建错误地invalidate了某个层，清除缓存并不能解决根本问题。 managing dependencies in Capacitor projects 在__CAPGO_KEEP_0__项目中管理依赖项的实用指南值得保存.
如果你的目标是更广泛的机器清理，而不是包管理问题，系统级别的指南也可以提供帮助。 Mac开发者想要 清除Mac用户的应用缓存
经常发现，包管理器只是存储问题的一部分。
何时不应使用Yarn清除缓存
不要将Yarn清除缓存作为每个安装问题的第一反应.
| 在有证据表明存在陈旧或损坏的包状态时使用它。 | 在问题更可能是： |
|---|---|
| 文件锁定漂移 | Review yarn.lock 一致性地检查和重新安装修改 |
| 工作区解析问题 | 检查工作区配置和安装行为 |
| Docker重建缓慢 | Review层次顺序和缓存持久性 |
| CI不匹配 | 验证实际恢复的目录 |
如果环境错误导致安装错误，仅清除缓存只会使下一次错误安装更慢。
这项区分节省了时间。大量的调试浪费来自对缓存的误解，认为它像一个魔法重置按钮一样。
清除Yarn Classic v1中的缓存
Yarn Classic遵循许多开发人员仍然假设所有Yarn版本都遵循的方式。它使用一个 全局缓存 在用户目录中，并 yarn cache clean 清除该共享缓存。 Yarn Classic的文档描述了它的方式，并指出缓存在下一次 yarn 或 yarn install 在用户目录中运行的模型中重新填充 the Yarn Classic缓存CLIdocs.
命令实际上删除了什么
对于Yarn v1，清理命令的默认行为是直接的：
yarn cache clean
该命令清除了共享缓存，而不是仅清除当前项目。如果您在同一台机器上工作多个仓库，
这很重要。下一次在其中任何一个仓库中安装时，可能需要重新获取包。
Yarn Classic 的实用序列通常如下:
- 首先运行清理命令：
yarn cache clean - 如果需要，请删除本地安装的艺术品：
node_modules当状态仍然不一致时，重新安装从头开始通常是下一个候选项。 - 重新安装从头开始： 再次运行
yarn install确认依赖图表解析正确。
如何验证缓存位置
当您想要直接检查或删除缓存目录时，Yarn Classic 给您路径：
yarn cache dir
这在 CLI 命令似乎无法解决问题时很有用，或者在共享或容器化环境中需要确认哪个用户账户拥有缓存目录时很有用。
如果您正在使用较旧的工具链并试图保持本地设置可预测，这个关于 一步一步安装 Capacitor CLI 的教程 __CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__ __CAPGO_KEEP_0__.
__CAPGO_KEEP_0__ __CAPGO_KEEP_0__ 环境假设倾向于泄露到调试中，这是一个有用的提醒。
命令细节之前，以下是一个快速的可视化解释：
Berry中的关键命令
Modern Yarn文档 yarn cache clean 移除 共享缓存文件，并且暴露了两个重要switch选项在 当前Yarn缓存清理命令参考:
yarn cache clean清除Yarn的共享缓存文件。yarn cache clean --mirror清除全局缓存而不是本地项目缓存。yarn cache clean --all清除全局缓存文件和当前项目的本地缓存文件。
这给了你比Yarn v1更有意图的工作流程。
| 目标 | 命令 |
|---|---|
| 清除默认共享缓存范围 | yarn cache clean |
| 目标全局镜像缓存 | yarn cache clean --mirror |
| 对本地和全局缓存文件进行全面重置 | yarn cache clean --all |
使用 --all 当您想实现“完全重新开始”的最接近的效果时使用。使用 --mirror 当您知道问题出在全局缓存层，并且不想清除项目中的所有内容时
决策点： 在Berry中，选择错误的范围是缓存清除看起来“什么都没做”的主要原因之一。
这就是实用差异。Yarn Classic默认情况下是广泛的。Berry是以明确的设计为目标的。
Yarn缓存最佳实践：CI/CD和Docker
在CI/CD中，盲目清除Yarn缓存通常是一个错误。它看起来安全，因为它移除了状态，但它经常移除了速度和可重复性的管道依赖的状态。
更有用的问题是： 您缓存的是什么，恢复的是什么？
为什么在管道中清除缓存往往是错误的动作
一个CircleCI讨论捕捉到了许多团队在实际项目中遇到的失败模式。慢速安装并没有通过缓存清除来解决，因为瓶颈并不是陈旧的包存档。它是fetch和link行为、缓存目录不匹配以及缺失的 node_modules 路径在缓存集中的描述，见到 CircleCI Yarn缓存线程.
这很重要，因为CI系统经常将潜在原因隐藏在一个模糊的症状后面：“安装慢”或“依赖步骤不稳定”。开发人员然后清除缓存，重新运行，并没有获得任何有意义的改进。
常见的管道错误包括：
- 缓存错误的目录： 恢复步骤完成，但Yarn并没有使用恢复的位置。
- 忽略工作区路径： 根依赖可能在工作区安装时重新建立。
- 构建 Docker 层次顺序错误： 源文件code的拷贝会使依赖层失效，因此每次安装包都会重新运行。
在 CI 环境中，由于配置错误导致的缓存失效看起来与缓存损坏的缓存相同。
如果您在自动化环境中构建移动应用程序，这也就是发布工具进入的场景。团队经常将GitHub Actions 或 CircleCI 与发布和更新系统结合使用。在更广泛的工作流程中，有一个选项是 Capgo’s CI/CD setup for Capacitor apps，与您的包管理器和构建缓存策略一起使用。
更好的 CI 和 Docker 方法
故意使用缓存失效，而不是情绪化地使用它。
对于 CI，一个可靠的模式如下：
- 基于依赖状态的缓存： 与
yarn.lock相关的Yarn配置文件。 - 安装前恢复: 恢复的路径必须与Yarn在该环境中使用的路径匹配。
- 一致安装: 在不可变的设置中，使用强制锁文件正确性的安装模式。
- 在真实变化时失效: Yarn版本更改、锁文件更新或缓存路径更改是重建缓存的好理由。
对于Docker，原则是类似的:
- 首先复制依赖项清单: 尽可能将依赖项安装层与应用程序源代码分开。
- 在镜像构建时避免不必要的清理: 删除同一构建内的缓存经常会移除有用的层重用。
- 明确用户所有权： 由 root 创建的缓存目录可能会在非 root 运行用户安装时造成后续安装失败。
一个简短的决策表会有所帮助：
| 场景 | 比起 yarn cache clean |
|---|---|
| 更好的动作 | CI 安装缓慢后恢复 |
| 验证缓存路径和恢复顺序 | 工作区仍然重链接 |
| 缓存相关工作区安装的艺术 | docker 重建重新运行安装过程中会导致重复安装问题 |
| One bad build after dependency change | 重新加载缓存后重建 |
在 CI 中只在确认陈旧缓存内容是实际问题后使用 Yarn 清除缓存。通常，解决方案是改善缓存设计。
常见 Yarn 缓存错误的故障排除
最令人沮丧的缓存 bug 是那些在清除缓存后仍然存在的 bug。您运行一个目标清洁、重新安装和 Yarn 还是从旧包中拉取包。到那时，人们很容易认为注册表有问题或锁文件被诅咒了。
Yarn 文档中有一个历史问题，说明了为什么会这样发生。开发人员报告说 yarn cache clean <package-name> 可能会留下旧副本在 cache/.tmp，这意味着安装一直使用陈旧版本，直到临时目录被删除或进行了全面的清洁，正如在 中讨论的 Yarn 关于陈旧缓存艺术品的问题中所讨论的那样。 .tmp.
当目标清洁仍然留下陈旧的包后
The lesson is simple. 的教训很简单。
如果您怀疑版本陈旧而不是广泛的损坏，使用以下顺序：
- 首先进行明显的检查： 确认您正在调试的包版本和源都是预期的：
- 不要对包特定的清理太有信心： 针对性清理可能会留下临时文件：
- 升级到全缓存清除： 如果陈旧版本持续存在，清理更广泛的缓存范围：
- 手动检查临时缓存路径： 在较旧的设置中，
cache/.tmp可能是缺失的部分：
当一个包始终解析到旧的工件时，临时缓存文件往往是首先检查的位置，尤其是在目标清理失败后：
看起来像缓存问题的权限和环境问题
不每个“缓存错误”都是缓存内容问题。
在Docker、多用户Linux系统或CI运行器中，可能会遇到权限失败，因为缓存目录由一个不同用户拥有，而Yarn进程运行的用户不同。在这种情况下，清除缓存不会解决问题，直到拥有权问题得到解决。实践方法是以正确用户运行Yarn，或者在重新安装之前修复目录拥有权。
这种问题通常表现为陈旧缓存，因为安装在不同环境中不一致。解决方案是操作性，而不是包相关的。
关于清除Yarn缓存的常见问题
清除Yarn缓存是否安全
是的。在正常开发中，这是一个安全的操作，因为你正在删除缓存的包艺术品，而不是删除应用程序源码。Yarn可以在下一次安装时重新获取所需的内容。
交易是时间。清除缓存意味着下一次安装可能需要下载或重建更多内容。
应该多久清除一次
只有当你有理由时。
Yarn清除缓存不应该是健康项目的例行维护。如果你将其放入每个工作流程中，习惯性地使用它，你会减慢本地安装速度并破坏CI缓存。使用它时，依赖项陈旧，安装看起来有问题，或者你需要在调试期间进行有意的重置。
会影响生产构建吗
不直接。清除本地或CI缓存不会改变你提交的应用程序code。
在环境中改变的是准备构建的环境。如果您的生产流水线依赖于缓存的安装艺术品，清除它们可能会使构建速度变慢或暴露隐藏的可复制性问题。
什么是最简单的实用规则？
遵循最小的清理规则以匹配问题。
对于本地调试，首先使用Yarn在该项目中使用的缓存范围。对于CI和Docker，修复缓存设计之前不要开始清除缓存。并且，当一个包特定的清理不起作用时，假设临时文件或环境不匹配之前不要假设Yarn是破损的。
如果您的团队发布Capacitor应用并需要在依赖关系或构建问题之后清洁的发布流水线， Capgo 是将JavaScript和资产更新交付到商店而不必等待商店审查，同时保持您的构建和发布过程与包缓存调试分开的选项。
