文章目录
-
- 前言
- 一、缓存优化解决重复劳动
- 二、矩阵不是越大越好
- 三、收紧触发条件
- [四、设计 job 关系](#四、设计 job 关系)
- 五、把工作流当成长期维护对象
- 总结
前言
很多团队第一次把 GitHub Actions 接进项目，目标都很一致，先跑通再说。可一旦工作流开始频繁执行，问题就会很快暴露出来。一次提交跑二三十分钟，PR 一多就开始排队，文档改动也触发整套 CI，构建时间越来越长，开发节奏也会被拖慢。工作流能跑通，只能说明它可用；跑得快、跑得稳、跑得值，才决定它是不是一套合格的工程流程。
GitHub Actions 本身已经给了很多能直接提效的能力，关键在于有没有把它们用对。缓存可以减少重复下载和重复安装，矩阵可以把兼容性验证并行展开，路径和分支过滤可以减少无意义执行，job 依赖和 artifact 则决定了一条流水线能不能真正拉开并行度。把这些点串起来，工作流的执行时间通常都能明显缩短。
一、缓存优化解决重复劳动
GitHub Actions 的运行环境本质上是一次性环境。每次 workflow 启动，很多依赖、工具链和包管理器缓存都要重新准备。如果项目稍微大一点，依赖安装和构建准备往往就是最先拖慢速度的部分。缓存的价值很直接，不是让工作流变复杂，而是把那些不需要每次都重来的步骤先省掉。GitHub 的缓存机制按 key、cache version 和分支范围去匹配，先找精确 key，再找前缀匹配和 restore-keys，当前分支找不到时，还会继续尝试默认分支。
缓存策略里，最核心的不是 path，而是 key。key 过于宽泛，会导致不该复用的缓存被拿回来；key 过于细碎，又会让缓存命中率很低。更稳妥的做法，是把真正影响依赖结果的因素放进 key，比如操作系统、语言版本、锁文件哈希。对 Node.js、Python、Java 这类常见技术栈，优先考虑对应的 setup-* action 自带缓存能力，通常会比自己手写一套缓存逻辑更稳。现在 GitHub 已经把几类常见包管理器的缓存支持整理得比较清楚，npm、Yarn、pnpm 对应 setup-node，pip、pipenv、Poetry 对应 setup-python，Gradle 和 Maven 对应 setup-java。
缓存也不是没有代价。默认情况下，超过 7 天没有被访问的缓存会被清理，仓库默认总缓存容量是 10 GB。现在这个上限已经不是完全写死的，可以由企业、组织或仓库管理员调大，但超出默认额度的部分会计费。缓存如果切得太碎，或者频繁产生新 key，很容易出现刚存进去又被淘汰的情况，最后反而进入高频创建和删除的状态。还有一点不能忽略，缓存路径里不要放凭据、token 或登录信息，因为有读取权限的人以及来自 fork 的 PR 场景，都可能间接接触到缓存内容。
二、矩阵不是越大越好
很多团队第一次用矩阵，会下意识把所有系统、所有语言版本、所有环境组合全都堆进去。这样当然全面，但也很容易把 workflow 变成一个资源黑洞。矩阵真正有价值的地方，在于把本来串行完成的兼容性验证拆成并行任务，而不是把所有可能组合都机械跑一遍。
GitHub Actions 的矩阵机制本身很直接，定义多个变量之后，它会自动按组合展开多个 job。配合 include 和 exclude，可以对特殊组合做精细调整。真正实用的经验是，把主支持版本做完整覆盖，把边缘版本收缩到必要范围。对大多数项目来说，不需要为了形式上的全覆盖，把每一个不重要的组合都付出同样成本。
矩阵还有两个参数特别关键。一个是 fail-fast，一个是 max-parallel。fail-fast 默认思路是，只要关键 job 失败，就取消其他正在进行或排队中的矩阵任务，这对节省资源很有用；但在排查多版本兼容问题时，把它关掉往往更方便，因为你能一次性看到多个失败结果。max-parallel 则控制矩阵任务同时能跑多少个，它的意义不是让并行变慢，而是防止你把 runner 资源一次性打满，尤其在仓库并发有限或者矩阵组合很多时，这个参数非常有必要。
三、收紧触发条件
很多工作流慢，不只是单次执行慢，而是执行次数本身就太多。文档改了触发完整测试，非关键分支也跑重型构建，PR 打开、同步、关闭全跑一遍，最后问题不只是耗时，而是整个 Actions 队列被大量低价值任务占住。
GitHub Actions 在触发层已经给了足够多的过滤能力。push 和 pull_request 可以配 branches、branches-ignore、paths、paths-ignore，workflow_dispatch 可以做手动触发，workflow_call 可以把公共逻辑抽成复用工作流。真正需要注意的，是这些条件之间不是随便叠加，而是同时生效。只要同时定义了 branch 过滤和 path 过滤，workflow 只有在两个条件都满足时才会运行。这个细节非常重要，因为很多团队以为只加一个 paths-ignore 就能解决问题，实际上往往还需要结合分支策略一起收口。
另一个经常被忽略的点是，工作流如果因为路径过滤、分支过滤或者 commit message 条件被跳过，而这个检查又被 PR 设成必需检查，那么它会保持 Pending 状态，PR 也会因此被卡住。这意味着，触发条件不能只从省资源的角度设计，还要考虑分支保护规则和合并体验。很多团队在这里踩坑，不是因为语法不会写，而是没有把工作流过滤逻辑和仓库合并策略一起考虑。
四、设计 job 关系
工作流优化做到后面，最值得下手的地方通常不是某一条命令再抠几秒，而是 job 之间的关系有没有设计合理。很多团队会把 lint、test、build、package、deploy 一股脑塞进一个长 job 里，从头跑到尾。这样配置简单，但会把本来可以并行的事情全部串起来，最后总耗时一定偏长。
更合理的做法，是把检查型任务尽量拆开。lint、单元测试、类型检查这些可以各自独立运行，真正需要依赖上一步结果的，再通过 needs 串起来。build 产物如果还要给后续 job 使用，就通过 artifact 传递，而不是在同一个 job 里硬串到底。artifact 和缓存看起来都在存文件，但用途完全不同。缓存更适合存依赖这类跨运行复用的内容，artifact 则更适合在同一次 workflow 里传递构建结果、测试输出、日志和二进制产物。
如果团队里有多个仓库，或者同一个仓库里有多条相似的工作流，还应该尽早把重复逻辑抽到 reusable workflow 里。通过 workflow_call，可以把公共构建流程、部署流程、检查流程收成一个被调用的工作流，并通过 inputs 和 secrets 传参。这样做的直接收益不是单次运行速度立刻飞起来，而是减少维护分叉，让优化动作能一次改动，多处生效。工作流复用做得越早，后面性能优化和稳定性治理的成本越低。
五、把工作流当成长期维护对象
GitHub Actions 的性能优化，不是一篇文章改几个 YAML 就能彻底结束的事情。
缓存命中率会变，仓库规模会变，依赖会变，团队提交流量也会变。真正有效的方式，是把 workflow 当成正式工程资产来维护，而不是把它看成写完就别动的配置文件。
缓存有没有命中，矩阵有没有跑过头，哪些 job 最耗时，artifact 是否过大，这些都值得定期看。GitHub 现在对缓存本身还有明确的速率限制，比如每个仓库每分钟最多 200 次缓存上传、1500 次缓存下载，规模一大就可能碰到这些边界。到了这个阶段，优化已经不只是写法问题，而是工作流设计问题。
总结
GitHub Actions 性能优化真正有用的，不是某一个技巧，而是你能不能把它看成一套完整的流水线治理问题。先用缓存减少重复劳动，再用矩阵把兼容性验证并行展开，再用路径和分支过滤减少无意义执行，最后通过 needs、artifacts 和 reusable workflows 把 job 关系重新整理清楚。做到这一步，工作流提速通常不是小幅改善，而是整条 CI/CD 体验都会变顺。
不要让依赖每次重装，不要让所有组合都无脑跑，不要让无关改动触发完整流程，也不要把本来能并行的事情全写成串行。工作流一旦按这个思路重构，性能通常就会明显上来。