你运行 yarn install, 依赖项更新后仍然解析到旧构建。或者你的笔记本电脑安装正常，而CI在无害的锁文件变更后突然失败。或者Docker重建拖延，尽管你正在“使用缓存”。
人们通常在这个时候开始寻找 清除Yarn缓存 然后粘贴他们找到的第一个命令。
有时这有效，有时这解决不了问题。原因很简单：Yarn的缓存行为取决于正在运行的Yarn版本，以及 Yarn Classic v1 和 context":"Page/area：Capgo营销网站。角色：短的UI标签或导航项。见于：页面trust.astro。消息键`and` (And)。 Yarn Berry v2+
之间的差异足够大，以至于改变正确的命令和正确的调试策略。 yarn cache clean大多数指南会停在
上面。然而，这才刚刚开始。真正重要的是缓存范围，项目是否使用本地缓存还是共享缓存，以及真正问题是否就是缓存本身。 在CI和Docker中，缓存策略不当往往会比陈旧的包存档带来更多痛苦。
- 目录索引
- 何时和为什么清除Yarn缓存
- 在Yarn Classic v1中清除缓存
- Yarn Berry v2+中的现代缓存管理
- CI/CD和Docker中的Yarn缓存最佳实践
- 解决常见的Yarn缓存错误
- 关于清除Yarn缓存的常见问题
你的构建出现问题，Yarn缓存可能是原因
一个熟悉的模式如下。您将包的版本升级，pull最新的更改，重新运行安装命令。命令完成，但应用程序仍然表现得像旧依赖项存在一样。然后有人建议清除缓存，现在您正在思考是否这是一个真正的解决方案还是只是迷信。
它可以是一个真正的解决方案。它也可以是一个分散。
缓存问题通常会以几个可预测的方式出现。一个本地包不会刷新。CI pull一些意外的东西。一个新分支的行为与主分支不同，尽管锁文件说应该匹配。您已经在追逐更广泛的管道不稳定性时，如果您正在追逐更广泛的管道不稳定性，帮助您将缓存调试与更系统的构建审查结合起来，例如本指南 解决Capacitor CI/CD pipeline中的构建故障.
实用规则： 将 Yarn 清除缓存视为诊断工具，而不是维护仪式。
困难在于 Yarn 在不同时间点改变了其缓存模型。在旧项目中，缓存是共享的。在新项目中，缓存清除可以局部到项目，全球，或者两者都取决于命令标志。因此，当同事说“清除 Yarn 缓存”，第一问应该是： 哪个 Yarn？
因此，一个好的缓存修复从上下文开始。机器或 CI 运行器。Yarn v1 或 Berry。共享缓存或项目缓存。了解这些后，命令就变得精确而不是盲目。
何时何地清除 Yarn 缓存
清除 Yarn 缓存在某些特定故障模式下有意义。它最有用的是当您需要移除陈旧的包裹艺术品、恢复从断开的下载状态或故意清除存储的包裹以便 Yarn 从头重建时。
指示缓存问题的症状
某些情况是强缓存候选者：
- 依赖项拒绝更新： 您改变了版本，或者重新构建了一个本地包，但安装仍然拉取一个较旧的artifact。
- 安装失败的方式让人觉得是有状态的： 一个机器可以正常工作，另一个机器就不行，重新运行相同的命令会不断地重现相同的错误结果。
- 您需要回收本地磁盘空间： 这在开发者机器上更为重要，而不是在短暂的CI环境中。
其他情况看起来像缓存问题，但实际上并不是。 如果您的lockfile意外改变了，如果工作区设置不一致，或者如果Docker构建错误地invalidate了一个层，清除缓存并不能解决根本问题。 开发团队在处理原生工具、JavaScript依赖项和插件更新时经常遇到这种情况。在这种情况下，这个关于管理__CAPGO_KEEP_0__项目依赖项的实用概述值得保存。 managing dependencies in Capacitor projects 何时不应该使用Yarn清除缓存
在__CAPGO_KEEP_0__项目中管理依赖项 清除Mac应用程序缓存 何时不应该使用Yarn清除缓存
在__CAPGO_KEEP_0__项目中管理依赖项
不要将 Yarn 清除缓存作为每次安装问题的首要响应。
在有证据表明缓存或包状态已过时或损坏的情况下使用它。跳过它，问题更可能是：
| 情况 | 更好的第一步 |
|---|---|
| 锁文件漂移 | 查看 yarn.lock 更改并重新安装一致 |
| 工作区解析问题 | 检查工作区配置和安装行为 |
| docker 重建缓慢 | 查看层次顺序和缓存持久性 |
| CI 不匹配 | 确认哪些目录实际上被恢复 |
如果安装错误是因为环境错误，清除缓存只会使下一次错误安装变慢。
这项区别会节省时间。大量的调试浪费来自于对缓存的误解，认为它像一个魔法重置按钮一样。
Yarn Classic v1 中的缓存清除
Yarn Classic 的行为与许多开发者仍然认为所有 Yarn 版本都有的行为相同。它使用一个 全局缓存 在用户目录中， yarn cache clean 并且 yarn 清除该共享缓存。Yarn Classic 的文档描述了它的方式，并且注意到缓存在下一次 yarn install 或 在用户目录中使用的模型中描述的 Yarn Classic 缓存 CLI 文档.
命令实际上删除了什么
对于 Yarn v1，默认的清理命令很直接：
yarn cache clean
这个命令清除了共享缓存，而不是仅仅清除当前项目。如果您在同一台机器上工作多个仓库，那么这很重要。下一次在任何仓库中安装包可能需要重新下载包。
这种共享缓存设计是 Yarn v1 可能会产生混淆的跨项目行为的原因之一。缓存中的陈旧 artifact 可能会存活很长时间，影响不同的仓库，尤其是在本地包开发涉及时。
对于 Yarn Classic，通常的实践顺序如下：
- 首先运行清理命令：
yarn cache clean - 如果需要，清除本地安装 artifact：
node_modulesis 通常是下一个候选项，当状态仍然看起来不一致时。 - 重新从头安装： 再次运行
yarn install并确认依赖图解析为期望的结果。
如何验证缓存位置
当您想直接检查或删除缓存目录时，Yarn Classic会给您路径：
yarn cache dir
这在CLI命令看起来似乎无法解决问题时很有用，或者在共享或容器化环境中需要确认缓存目录的用户账户时很有用。
如果您正在使用较旧的工具链并且希望保持本地设置的可预测性，这个关于 安装Capacitor CLI的逐步指南 与清洁依赖项重置搭配使用时效果最佳。
手动缓存检查通常比第二次盲目清除命令更有价值。
对于v1项目，思维模型很简单。一个共享缓存，一个广泛的清除命令，下一次安装会重新填充您删除的内容。
Yarn Berry v2+中的现代缓存管理
Yarn Berry改变了对话。如果您习惯于使用Yarn v1，最大调整就是缓存清除不再仅仅是“清除全局存储并尝试再次安装”。Berry支持更精确的控制，这在您知道自己要目标时很有用。
Berry改变了缓存模型
在现代Yarn中，缓存行为与项目本身更密切相关。这符合Berry更广泛的项目级控制、插件式和工作流程的方法，其中依赖项可以与仓库一起存活，而不是在单个机器级缓存模型中存活。
为什么旧的建议会误导你。一个学习了Yarn v1的团队成员可能会期望一个命令可以清除全球的所有内容。在Berry中，你需要以 scope.
为单位思考。如果你处理不同设备和web管道的构建输出，那么同样的思维方式也适用于包管理之外的其他地方。这对 types of builds 的比较是一个有用的提醒，环境假设往往会渗透到调试中。
Here’s a quick visual explainer before the command details:
在Berry中，以下命令很重要
Modern Yarn documents yarn cache clean 作为清除 shared cache files的命令，并且它暴露了两个重要switches在 the current Yarn cache clean command reference:
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并未使用恢复的位置。
- 忽略工作区路径： 根依赖项可能恢复，而工作区安装工作仍需要重新链接。
- 在CI中，缓存失效由坏配置引起，看起来与缓存损坏的缓存很相似。 如果您在自动化环境中构建移动应用程序，这也就是发布工具进入的场景。团队经常结合code Actions或CircleCI与发布和更新系统。其中一个选项是在更广泛的工作流中使用code’s CI/CD设置__CAPGO_KEEP_1__应用程序
，并与您的包管理器和构建缓存策略一起使用。
GitHub Capgo’s CI/CD setup for Capacitor apps__CAPGO_KEEP_0__
A CI 和 Docker 的更好方法
故意地使用缓存失效，而不是情绪化地使用它。
对于 CI，一个可靠的模式如下：
- 基于依赖项状态的缓存： 将缓存键绑定到
yarn.lock和相关的 Yarn 配置文件。 - 在安装之前恢复： 确保恢复的路径与 Yarn 在该环境中使用的路径匹配。
- 一致地安装： 在不可变的设置中，使用强制锁文件正确性的安装模式。
- 在真实的变化时失效： Yarn 版本变化、锁文件更新或缓存路径变化都是重建缓存的好理由。
对于 Docker 来说，原则是类似的：
- 首先复制依赖项清单： 尽可能将依赖项安装层与应用程序源代码分开。
- 避免在镜像构建中进行不必要的清理： 在同一构建中删除缓存通常会移除有用的层重用。
- 明确用户所有权： 由 root 创建的缓存目录可能会在非 root 运行时用户安装时导致失败。
一个简短的决策表会有所帮助：
| 场景 | 比原来的更好的动作 yarn cache clean |
|---|---|
| CI 安装在恢复后变慢 | 验证缓存路径和恢复顺序 |
| 工作区仍然频繁重新链接 | 缓存相关工作区安装的艺术品 |
| Docker重建重新安装 | 重新排列依赖文件的层次 |
| 依赖项变化后出现的坏构建 | 清除缓存键，然后重新构建 |
在CI中仅在确认缓存内容过时时才使用Yarn清除缓存。通常，解决方案是更好的缓存设计。
解决常见的Yarn缓存错误
最令人沮丧的缓存错误是那些在清除缓存后仍然存在的错误。您运行一个目标清洁，重新安装，Yarn仍然从旧包中拉取。到那时，人们很容易认为注册表有问题或锁文件被诅咒。
Yarn的一个文档历史问题解释了为什么会这样发生。开发人员报告说 yarn cache clean <package-name> 可能会留下一个旧副本在 cache/.tmp，这意味着安装一直使用过时的版本，直到临时目录被删除或进行了全面的清理，正如在 关于Yarn中陈旧缓存物件的问题是 .tmp.
即使进行了针对性的清理，陈旧的包依然会留下
教训很简单 部分清理并不是总是足够的
如果您怀疑是版本陈旧而不是广泛的损坏，使用以下顺序
- 首先进行明显的检查 确认您正在调试的包版本和来源
- 不要对包特定的清理太有信心 针对性的清理可能会留下暂时的物件
- 升级到全面的缓存清除 如果陈旧的版本仍然存在，清除更广泛的缓存范围
- 手动检查临时缓存路径 In较旧的设置中，
cache/.tmp可能是缺失的关键部分。
当一个包始终解析为旧的工件时，临时缓存文件通常是首先检查的位置，尤其是在目标清洁失败后。
看起来像缓存问题的权限和环境问题
并不是每个“缓存错误”都是缓存内容问题。
在Docker、多用户Linux系统或CI运行器中，您可能会遇到权限失败，因为缓存目录由一个不同的用户拥有，而Yarn进程则运行在另一个用户下。在这种情况下，清除缓存不会解决问题，直到拥有权问题得到解决。实践方法是以正确的用户身份运行Yarn，或者在重新安装之前修复目录拥有权。
这种类型的问题通常表现为陈旧的缓存，因为安装在不同环境中不一致。解决方案是操作性的，而不是与包相关的。
关于清除Yarn缓存的常见问题
清除Yarn缓存是否安全
是的。在正常开发中，这是一个安全的操作，因为您正在删除缓存的包工件，而不是删除应用程序源代码。Yarn可以在下一次安装时重新获取所需的内容。
交易是时间。清除缓存意味着下一次安装可能需要下载或重建更多内容。
您应该多久清除一次
只有当你有一个合理的理由时。
Yarn 清除缓存不应成为一个健康项目的常规维护。如果你将其添加到每个工作流程中，会减慢本地安装速度并破坏 CI 缓存。只在依赖项过时、安装看起来被破坏或你需要故意重置调试时使用它。
会影响生产构建吗
Not directly. Clearing your local or CI cache doesn’t change the application code you’ve committed.
它会改变的是准备构建的环境。如果你的生产管道依赖于缓存的安装艺术品，清除它们可能会使构建速度变慢或暴露隐藏的可重复性问题。这在调试时很有用，但不要在发布脚本中随意添加它。
什么是最简单的实践规则
只清除与问题相关的最小缓存。
对于本地调试，从项目中使用 Yarn 的缓存范围开始。对于 CI 和 Docker，修复缓存设计之前不要清除缓存。并且，当一个包特定的清除不起作用时，先考虑临时文件或环境不匹配，而不是认为 Yarn 是有问题的。
如果你的团队发布 Capacitor 应用程序并需要在依赖项或构建问题后清理发布管道 Capgo 是将 JavaScript 和资产更新分离于等待商店审查的同时，保持你的构建和发布过程与包缓存调试分离的方法。
