配了三年 CI/CD，今天才发现每次 workflow 跑起来第一步都是在等环境装完——今天 GitHub 把这件事用自定义镜像彻底原生化了

做过大规模 CI 的团队都知道这个画面：workflow 一启动，第一步往往不是跑你的代码，而是等一堆 setup 动作——Node 版本装上了、Python 环境装好了、证书配上了、内部二进制下载完了。每次跑、每个 job，都是从零开始。这不是 bug，是标准 GitHub-hosted runner 的默认行为。

但这件事在 2026 年 4 月被彻底改了。

GitHub Actions Custom Images（自定义镜像）正式 GA，所有 GitHub Team 和 Enterprise Cloud 计划都可以用，它的思路很简单：别每次跑的时候再装，直接把环境打包进镜像里。

三步把你的 CI 环境变成一张快照。

第一步，建一个镜像生成 runner。在 Actions 设置里建一个临时 runner，平台选 Linux x64、Linux ARM64 或 Windows x64，runner 规模无所谓，临时用完就删。

第二步，跑一个带 snapshot 关键字的 workflow，核心是这个 snapshot 关键字——每次成功跑完，GitHub 自动生成一个新版本，版本号自动 minor 递增。如果想更精细控制，可以手动 pin 到某个 major 版本。

第三步，在 Actions 设置里找到 Custom Images，找到你的镜像，创建一个使用这张镜像的 larger runner，然后在 workflow 里 runs-on 指定它。工具链已经在镜像里了，job 启动直接进入代码执行，setup 步骤全部跳过。

为什么这件事值得认真对待？包含 10 个 action/setup 步骤的典型 Node.js workflow，setup 阶段平均占总耗时的 20-40%。如果 workflow 跑了 5 分钟，其中可能有 1-2 分钟是在等环境就绪。对于高频 push 的 monorepo，这个损耗乘以 job 数量相当可观。

三个坑要先知道。

第一个坑是镜像本身要维护。GitHub 建议把镜像生成跑成每周定期任务，这样依赖更新和安全补丁能持续跟进。但镜像变成了一个额外的管理对象——需要制定版本策略、测试策略，镜像出问题影响面比单个 action 大得多。

第二个坑是镜像里的秘密管理。把证书、密钥、二进制直接 bake 进镜像有供应链风险：谁有权限改镜像？改完之后谁来验证？官方文档的建议是把镜像生成 runner 放在专用 runner 组里，不允许生产与开发仓库共享。

第三个坑是规模与成本的取舍。自定义镜像只能在 larger runner 上用，而 larger runner 按分钟计费比标准 runner 贵。镜像能省下 setup 时间，但 larger runner 的单价也要算进去——不是所有团队都划算。

下一步是从每周手动跑到 PR 自动触发镜像重建。如果你的团队已经有可信的镜像管理机制，最直接的下一步是用一个 scheduled workflow 每周自动重建镜像：on schedule cron 0 3 1，加上版本 pinning 策略和 runner group 访问控制，这套机制才能真正在团队里用起来而不是变成另一个看起来很美的实验。

参考资料：InfoQ 报道 https://www.infoq.com/news/2026/04/github-actions-custom-runners/ | GitHub 官方文档 https://docs.github.com/actions/how-tos/manage-runners/larger-runners/use-custom-images | GitHub Enterprise 四月更新 https://github.com/resources/insights/enterprise-content-roundup-april-26 | GitHub Actions Changelog https://github.blog/changelog/2026-04-02-github-actions-early-april-2026-updates/