GitHub Actions 挂了？CI 竟然跑满一小时，教你如何快速排查与切换

最近这两天，不少开发小伙伴在群里吐槽：自己的 Github Actions 是不是坏了？以前几分钟就能跑完的 CI 流水线，现在居然要跑一个小时！这简直比手动编译还慢，让人看着进度条血压飙升。

如果你也遇到了类似情况，别急着骂人，先静下心来排查一下问题。毕竟有时候是平台的大规模故障，有时候也可能是我们自己项目配置的锅。今天咱们就来聊聊，当 CI 突然变慢时，我们该怎么办，以及有没有什么更稳的“羊毛”可以薅。

当你发现所有项目的流水线都慢得离谱时，第一时间先去 GitHub Status 看看。如果是 GitHub 自身的服务器宕机或者由于基础设施升级导致的性能降级，那里通常会飘着红色的 Incidents。

这种情况下，除了等，基本没啥好办法。毕竟我们用的是免费额度或者是付费但受限于平台资源的 runner。不过，了解这一点能让你少走弯路，避免把时间浪费在无意义的代码优化上。

GitHub 状态页面报错

检查 GitHub 官方状态页

如果官方状态一切正常，但你的 CI 还是慢得像蜗牛，那就要反思一下了。很多时候，构建变慢是因为随着项目迭代，我们无意中增加了一些重量级的依赖或步骤。

检查依赖安装时间：是不是 npm install 或者 pip install 的时候，没有做缓存？GitHub Actions 提供了 actions/cache，一定要把 node_modules 或者依赖目录缓存起来，这能节省几十倍的下载时间。
构建步骤是不是臃肿了：看看你的 .yml 文件，是不是跑了一些不必要的测试？或者是每次都从零开始下载一个巨大的 Docker 镜像？试着精简一下 workflow，只跑最核心的逻辑。
并发竞争：如果你的开源项目突然火了，短时间内触发了几百次 CI，GitHub 可能会对你的账号进行限流，导致排队时间过长。适当调整触发条件，比如把 push 改为 pull_request，或者只在特定目录变动时触发。

GitHub Actions 虽然好用，但也不是唯一的出路。如果它频繁抽风，或者是你的项目对构建时效性要求很高，不妨考虑几个“平替”方案，甚至是多云备份。

1. GitLab CI

GitLab 自带的 CI/CD 功能非常强大，而且对于开源项目，它提供的免费 Runner 分钟数通常比 GitHub 更大方。如果你的配置文件写得规范，迁移成本其实并不算高。更重要的是，GitLab 的 Runner 有时候网络环境对我们更友好。

2. 自建 Runner（利用闲置资源）

这算是进阶玩家的“羊毛”了。如果你手头有闲置的 VPS、学生机，甚至是家里有台不关机的 NAS（比如群晖），完全可以搭建一个 GitHub Self-hosted Runner。

优点：完全掌控硬件资源，网络环境自定，不用担心 GitHub 官方的排队。对于私有项目，这样既安全又高速。
注意：一定要给 Runner 配置好安全策略，避免被恶意代码利用。对于 PR 的构建，建议不要直接使用有写权限的 Self-hosted Runner，或者使用容器化隔离。

3. 爬一圈其他羊毛

除了大厂，还有一些专注于云原生的平台提供免费的构建额度。比如 Woodpecker CI，它非常轻量，对 Docker 支持极佳，界面清爽，配置简单。如果你有一些边缘的计算资源，或者用了某些提供 CI 积分的云服务商，都可以尝试接入。分散风险是关键。

遇到 GitHub Actions 变慢确实搞心态，但这也提醒我们，过度依赖单一平台是有风险的。作为技术人员，保持对工具链的敏感度，多尝试几种 CI 方案，无论是为了学习技术，还是为了保证项目发布的稳定性，都是百利无一害的。

下次再遇到这种情况，不妨先喝杯茶，查查状态页，然后顺手把自己的 Runner 配置一下。毕竟，掌控时间的感觉，才是最爽的。