你运行 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一些意外的东西。一个新分支的行为与主分支不同，尽管锁文件说应该匹配。如果您已经在追逐更广泛的管道不稳定性，帮助缓存调试与更系统的构建审查一起使用，例如本指南 修复CapacitorCI/CD管道中的构建故障.
实践规则： 将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 清除缓存
何时不应该使用 Yarn 清除缓存 何时不应该使用 Yarn 清除缓存 何时不应该使用 Yarn 清除缓存
何时不应该使用 Yarn 清除缓存
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
| __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ |
|---|---|
| 情况 | __CAPGO_KEEP_0__ yarn.lock 检查变更并重新安装 |
| 工作区解析问题 | 检查工作区配置和安装行为 |
| Docker重建缓慢 | 检查层次顺序和缓存持久性 |
| CI不匹配 | 确认哪些目录实际上会被恢复 |
如果安装出错是因为环境出错，清除缓存只会让下一次错误安装变得更慢。
这点区分会节省时间。大量的调试时间浪费都是因为把缓存当作一个魔法重置按钮。
Yarn Classic v1 中的缓存清除
Yarn Classic 的行为与许多开发者仍然认为所有 Yarn 版本都有的行为相同。它使用一个 全局缓存 在用户目录中， yarn cache clean 并且 yarn 清除该共享缓存。 Yarn Classic 的官方文档就这样描述的，并且注意到缓存在下一次 yarn install 或 the Yarn Classic cache CLI docs.
__CAPGO_KEEP_0__
命令实际上删除了什么
yarn cache clean
对于 Yarn v1， 默认清理命令很直接：
该命令清除共享缓存，而不是仅清除当前项目。如果您在同一台机器上工作多个仓库，那么这很重要。下一个安装在任何仓库中可能需要重新获取包。
共享缓存设计是 Yarn v1 可能产生混淆的跨项目行为的一个原因。缓存中的陈旧 artifact 可能会存活很长时间，影响不同的仓库，尤其是在本地包开发涉及时。
- 对于 Yarn Classic，通常的实践顺序如下：
yarn cache clean - 首先运行清理命令：
node_modules如果需要，请删除本地安装 artifact： - is 通常是下一个候选项，当状态仍然看起来不一致时。 重新从头开始安装：
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 将 as removing缓存文件 shared cache files:
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__应用程序
If you’re building mobile apps in automated environments, this is also where release tooling enters the picture. Teams often combine GitHub Actions or CircleCI with distribution and update systems. One option in that broader workflow is Capgo’s CI/CD setup for Capacitor apps恢复步骤完成，但Yarn并没有使用恢复的位置。
A CI 和 Docker 的更好方法
故意地使用缓存失效，而不是情绪化地使用它。
对于 CI，一个可靠的模式如下：
- 基于依赖项状态的缓存： 将缓存键绑定到
yarn.lock和相关的 Yarn 配置文件。 - 在安装之前恢复： 确保恢复的路径与 Yarn 在该环境中使用的路径相匹配。
- 一致地安装： 在不可变的设置中，使用强制锁文件正确性的安装模式。
- 在真实的变化时失效： Yarn 版本更改、锁文件更新或缓存路径更改是重建缓存的好理由。
对于 Docker 来说，原则是类似的：
- 首先复制依赖项清单： 尽可能将依赖项安装层与应用程序源代码分开。
- 避免在镜像构建中进行不必要的清理： 在同一构建中删除缓存通常会移除有用的层重用。
- 明确用户所有权： 由 root 创建的缓存目录可能会在非 root 运行时用户安装时导致失败。
一个简短的决策表格有帮助：
| 场景 | 比上更好的行动 yarn cache clean |
|---|---|
| CI 安装在恢复后变慢 | 验证缓存路径和恢复顺序 |
| 工作空间仍然频繁重新链接 | 缓存相关工作空间安装的艺术品 |
| docker重建重新安装 | 重排层次结构依赖文件 |
| 依赖项变化后出现一次坏的构建 | invalidate缓存键，重新构建干净 |
仅在确认缓存内容过时是实际问题时，在CI中使用yarn清除缓存。通常，解决方案是更好的缓存设计
解决常见的yarn缓存错误
最令人沮丧的缓存bug是那些能够抵抗缓存清除的。您运行一个目标清洁，重新安装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 和资产更新分离于包缓存调试之外的方法，而不必等待商店审查，同时保持你的构建和发布过程独立。
