很多人对 GitHub Actions 的印象，还停留在"推完代码自动跑个 CI"。但最近刷一圈社区你会发现，这玩意儿早被玩成了"免费云服务器"：有人拿它免费盯着自己的网站挂没挂，有人用它把 Release 里的安装包自动同步到百度网盘，还有 AI 公司的工程师拿它跑夜间的自动化任务，一觉醒来结果已经躺在仓库里。
免费账户每个月能拿到 2000 分钟构建时长 + 500MB 存储。这笔"羊毛"说多不多说少不少，会算账的人能拿它干不少事；不会算的人，某天会突然发现流水线被锁死，页面上冷冰冰一行"用量已耗尽"。今天就把这本账算清楚，顺带把社区里验证过的几个实用玩法和容易踩的坑一次性讲完。
先搞清楚：免费额度到底有什么
免费计划的官方配置就四样，先记住这几个数字：
构建时长：2000 分钟/月。注意只针对私有仓库计费，公开仓库的 Actions 完全免费，不占额度。知乎
存储：500MB（构建产物 artifact 的存储空间）。
并发：最多同时跑 20 个 job。
操作系统倍率：Linux ×1、Windows ×2、macOS ×10。这条最容易被忽略——同样跑 10 分钟，macOS 的 job 会扣掉你 100 分钟。
一句话总结：公开仓库随便造，私有仓库精打细算，macOS 能不用就不用。
三种用法的算账模型
光看数字没感觉，套进真实场景算一遍就明白了（以下单次时长为社区常见配置的估算值，实际以你的工作流为准）：
场景一：低频夜间任务。 比如每天凌晨备份一次数据、跑一份报表、同步一次文件。一天 1 次、每次按 5 分钟算，一个月 30 次 × 5 分钟 = 150 分钟，只占额度的 7.5%。这是最划算的用法，剩下 90% 多的额度完全不影响你正常跑 CI。
场景二：多平台打包矩阵。 一个人想给 Windows、Linux、macOS 三平台打包，用 matrix 策略一次触发 3 个 job。按每个平台 12 分钟估算，一轮就是 12 × 2（Windows 倍率）+ 12 × 1 + 12 × 10（macOS 倍率）= 168 分钟/轮。也就是说，免费额度一个月大概只够你发 10 来次全平台版本——对周更的独立开发者够用，对日更就紧张了。
场景三：高频定时监控。 这是最容易翻车的。每 10 分钟检查一次网站，一天 144 次、一个月 4320 次，就算每次只跑 1 分钟也是 4320 分钟，直接爆掉 2000 分钟的额度。所以高频监控类任务要么放进公开仓库（免费不限量），要么把频率降到 30 分钟以上，这是条硬边界。
五个被社区验证过的实用玩法
玩法一：免费的网站可用性监控。 用 schedule 定时触发一个轻量脚本，curl 你的站点，失败就发通知（邮件、Telegram、钉钉都有现成 action）。商业监控服务动辄每月几十上百美元，这个方案在公开仓库里成本是零。知乎适合盯着自己的博客、小工具站、博客备案有没有掉。
玩法二：Release 产物自动同步国内网盘。 这是国内开发者的刚需痛点：GitHub Release 的下载速度经常让人崩溃。社区的成熟做法是打个 Tag 触发流水线，自动完成构建、打包、上传网盘，全程不用手动搬运。知乎版本一多，省下的不只是时间，还有"传错包"的事故率。
玩法三：夜间定时任务中心。 数据备份、爬虫拉数据、生成周报，甚至跑一些轻量的 AI agent 任务——有工程师分享过用 Actions 的夜间 cron 跑自动化外联任务，每个任务独立容器化，成本几乎为零。夜里机器替你干活，早上直接看结果。
玩法四：一键多平台打包。 自己只有一台 Windows 电脑，也能给三平台出安装包，靠的就是 matrix 策略。唯一提醒：算账时记得 macOS 的 10 倍倍率，非必要别把 macOS 加进日常构建，留给发版时用。
玩法五：自托管 runner，彻底绕开分钟数。 如果你手头有闲置电脑或一台便宜的 VPS，可以把它注册成自托管 runner。GitHub 对自托管 runner 不收分钟数，时长完全自由，代价是机器和电费自己出。私有仓库重度用户走到这一步基本是终局方案。
避坑清单：五个真有人会栽的坑
默认 90 天留存期会悄悄吃光存储。 500MB 存储按"GB-小时"计费，几个几十 MB 的 artifact 按默认 90 天躺着，额度很快就见底。知乎解法很简单：在 upload-artifact 步骤里加一行 `retention-days: 7`（按需调小），只留近期版本。
cron 是 UTC 时间。 想在北京时间凌晨 3 点跑任务，得写 UTC 的 19 点：`cron: ‘0 19 * * *’`。这是新手最常懵的一件事：为什么定时任务总在奇怪的点触发。
定时任务只在默认分支生效。 在开发分支上写了 schedule，合并不了主分支永远不会跑。另外注意，schedule 触发在高峰期可能有几分钟延迟。知乎别指望它像闹钟一样准点。
仓库闲置 60 天，定时任务会被自动禁用。 想恢复要去 Actions 页面手动重新启用。长期低频维护的仓库尤其要注意这条。
缓存别忘记用，但它不解决存储问题。 actions/cache 能把依赖安装从几分钟压到几十秒，单仓库上限 10GB，不占那 500MB 存储额度。构建慢先查缓存，别急着换平台。知乎
谁适合，谁该绕道
公开仓库用户：不用算账，随便用，这是 GitHub 给开源最实在的福利之一。
个人开发者/兴趣项目：低频夜间任务 + 偶尔发版，2000 分钟绰绰有余，重点是控制留存期和 macOS 用量。
私有仓库高频监控/重度多平台构建：免费额度撑不住，要么挪进公开仓库、要么上自托管 runner，别硬扛到流水线被锁。
团队协作：免费计划只够单人试水，团队场景直接看付费档。
值得继续盯的信号
一个明显的趋势：Actions 正在从"CI 工具"变成"通用自动化底座"。社区里已经开始把它和 n8n、AI agent 拼在一起玩自愈式流水线，也有人直接让 AI 编程助手帮你生成 Actions 配置——yaml 写不明白的，这条路值得试试。计费相关的政策这两年在持续调整，把用量通知打开，比什么都实在。
