GitHub把10亿次工作流藏进免费仓库

GitHub Actions每月运行超过10亿次工作流，但83%的开发者只用过基础模板。剩下的17%在干什么？他们在用代码片段把CI/CD流水线玩成自动化工厂。

这差距就像有人用瑞士军刀削苹果，有人用它造了一座木屋。今天还原几个被严重低估的Actions技巧——不是教程，是实战代码。

技巧1：矩阵构建的"偷懒"哲学

多版本测试是CI的标配，但复制粘贴十几个job的人依然遍地都是。GitHub Actions的矩阵策略(matrix)能把配置压缩到一行变量定义。

核心代码：用strategy.matrix把Node 18/20/22、Ubuntu/macOS/Windows的9种组合一次性跑完，YAML行数从90行降到12行。

更隐蔽的玩法是include字段——你可以给特定组合单独注入环境变量。比如只在Node 20+Ubuntu的组合里跑覆盖率检测，其他组合跳过。这对免费额度紧张的个人开发者很实在。

一个细节：fail-fast默认开启，意味着矩阵中任何一个job失败会立刻终止全部。大型项目建议关掉它，否则你修复完Linux问题才发现Windows也有坑，来回跑十几趟。

技巧2：缓存的"精准打击"

actions/cache被滥用的程度堪比console.log。很多人把整个node_modules塞进去，结果缓存命中率低于30%。

问题出在key的设计。正确的做法是锁文件哈希+操作系统标识+架构标识的三段式组合：

npm-${{ hashFiles('package-lock.json') }}-${{ runner.os }}-${{ runner.arch }}

这样同一台机器跑两次，只要package-lock.json没变，缓存秒命中。更进阶的玩法是分层缓存——把依赖安装和构建产物分开存，后者用git commit SHA做key，确保每次代码变更都重新构建，但依赖安装环节依然走缓存。

GitHub的免费账户有10GB缓存额度，超出后按时间LRU淘汰。一个中型前端项目如果缓存策略得当，能把CI时间从8分钟压到90秒。

技巧3：可复用工作流的"外包"思维

2021年GitHub推出reusable workflows时，社区反应冷淡。三年过去，它成了大型仓库治理的隐藏武器。

原理很简单：把通用的lint、test、build步骤抽成独立仓库，主仓库用一行uses调用。但多数人没意识到的是调用语法的变化——

jobs.call-workflow uses: owner/repo/.github/workflows/reusable.yml@main

@main可以换成任意git引用，包括PR分支。这意味着你可以在不影响主仓库的情况下，调试CI配置本身。更骚的操作是把敏感步骤（比如签名、发布）放在私有仓库的可复用工作流里，公开仓库只负责触发，权限彻底隔离。

一个踩坑记录：可复用工作流的secrets必须显式传递，不会自动继承。很多人迁移后发现部署失败，原因是密钥没传进去。

技巧4：GitHub Script的"临时脚本"

actions/github-script这个官方动作被严重低估。它让你在YAML里直接写JavaScript，操作GitHub API而不用新建一个JS文件。

典型场景：PR合并后自动打标签、issue创建时自动分配负责人、CI失败时@相关开发者。这些需求如果走传统路线，需要新建仓库、写代码、发npm包、维护版本。

用github-script，五行代码解决：

github.rest.issues.addLabels({ owner, repo, issue_number, labels: ['ci-failed'] })

更隐蔽的用法是读取workflow上下文——比如拿到触发当前运行的PR编号，去查该PR的修改文件列表，然后决定跑哪些测试。这种"动态决策"是静态配置做不到的。

技巧5：Composite Action的"伪代码"封装

如果你有一组shell命令在多个仓库重复出现，Composite Action是比可复用工作流更轻量的选择。它伪装成一个普通action，内部是多步骤的脚本集合。

发布流程也极简：不需要npm registry，不需要Docker Hub，直接推送到GitHub仓库的某个分支，引用时用@branch或@tag。

一个实战案例：某团队把"安装私有npm源+配置git身份+拉取子模块"封装成composite action，三个仓库的CI配置从各自20行变成统一一行uses。

维护成本的变化更可观——私有npm源地址变更时，改一处即可，不用逐个仓库发PR。

GitHub Actions的文档有个特点：基础用法写得详尽，进阶技巧散落在changelog和社区讨论里。这导致一个现象——官方博客2019年介绍的某个特性，到2024年还有人在Stack Overflow问"能不能做到"。

10亿次月运行量背后，是大量重复劳动和未被挖掘的自动化潜力。你现在的CI配置里，有多少行是可以删掉的？