Go CI 缩短 69% 的背后，缓存命中也可能一直拿错包
据 CloudX 发布的工程经验文章，团队通过调整 Go 项目的 GitHub Actions 缓存，把图表中的平均运行时间从约 131 秒降到 41 秒，并开源了相关实现。值得注意的不是一个可以复制到所有项目的“快 69%”，而是缓存命中之后，任务仍可能不断重复本来想省掉的工作。
作者：林岚｜OC 开发者生态编辑
据 CloudX 发布的工程经验文章，团队通过调整 Go 项目的 GitHub Actions 缓存，把图表中的平均运行时间从约 131 秒降到 41 秒，并开源了相关实现。值得注意的不是一个可以复制到所有项目的“快 69%”，而是缓存命中之后，任务仍可能不断重复本来想省掉的工作。
一句话结论：命中同一个缓存键，不代表拿到了当前任务最需要的缓存；工作负载隔离、更新策略和恢复成本，要一起设计。
缓存存在，为什么还要重算
CI 缓存不是持续更新的共享磁盘。GitHub Actions 的缓存条目具有不可变特征：相同键下的既有内容，不会因为后续任务产生了更完整的缓存就自动覆盖。
如果测试和静态检查共用同一个键，却产生不同的缓存内容，先完成并保存的任务可能决定后来大家能恢复到什么。对另一个任务而言，恢复成功只说明取到了归档，不说明归档里包含它需要的全部结果。
这里的“拿错包”是缓存用途不匹配，不是说 Go 会因此悄悄采用错误构建结果。Go 自身仍会判断已有条目是否适用；不适用时重新计算，表现通常是时间没有省下来。正因为正确性检查仍在工作，这类问题才容易隐藏在一片绿色的 CI 状态中。
给任务分路，还要允许缓存成长
CloudX 的实现将任务身份纳入隔离思路，并利用运行标识保存新条目，再通过恢复前缀寻找可用缓存。这能避免长期被最初那份不完整归档锁住，也让不同任务积累各自需要的结果。
但新增键不是没有代价。条目变多后，上传下载、容量、清理以及恢复选择都会影响收益。如果恢复一个大缓存花的时间比重新计算还长，命中率越高未必越快。
合理评估因此要拆开看：准备环境多久、恢复多久、真正执行多久、保存多久。只比较整个任务的总时长，可以发现变快了，却未必能解释为什么，也不利于判断下次工作负载改变后是否仍然受益。
69% 的口径不能跳过
原文标题强调约 69% 的缩短，图表给出的约 131 秒到 41 秒与这一比例相符。但正文另一处又出现约 180 秒的起点，两者不是同一基线。本文采用与标题对应的图表数字，不把两个起点混算。
作者还用历史提交估算减少重复测试执行的潜力。这类反事实计算可以帮助理解机会有多大，却不是已经从账单中核实的成本节约。等待时间、测试执行次数和最终计费，不能用同一个百分比代替。
这些数字也来自团队自己的项目环境。模块结构、测试分布、执行器速度和缓存容量都会改变结果；没有理由预期每个 Go 仓库换用同一方案后都获得相同比例。
先诊断，再替换基础环节
一个直接的排查方向，是看共享缓存键的任务究竟做了什么，以及日志中的命中是否真的减少了重复工作。若只是依赖下载已经很快，而测试本身昂贵，问题可能在另一层；若缓存恢复占了大半时间，继续增加缓存内容反而需要谨慎。
采用第三方 Action 还意味着把 CI 的一部分执行权交给新的维护者。团队需要审查实现、权限和版本固定方式，而不能仅因为性能图好看就替换所有流水线。
这篇经验最值得借鉴的，是把缓存当成有生命周期的数据产品：谁写、谁读、内容何时更新、什么时候该丢弃。命中只是开始，节省真实工作才是目的。
关键事实
- 来源：CloudX 工程文章与开源 Action。
- 数字口径：图表约 131 秒降至 41 秒，约缩短 69%；正文另有不同起点。
- 技术重点：缓存不可变、任务隔离与新条目保存策略。
- 适用边界：单团队工作负载结果，不是通用提速保证。
OC 判断
缓存优化最容易误判的指标，就是命中率。它只回答是否找到条目，不回答条目是否适用、是否足够新，以及取回来是否划算。把这些问题拆开，往往比继续扩大缓存更有价值。
为什么重要
- 对开发者：留意恢复成功但工作仍反复执行的情况。
- 对平台团队：将缓存传输与保存成本纳入性能评估。
- 对管理者：不要把历史模拟的节省比例直接计入实际成本收益。
评论
围绕这篇文章补充信息、提出问题或分享观察。