各位站长、开发者，今天给大家带来一期逐项核对过 GitLab 官方文档的 CI/CD 线报。
上一期我们核了 GitLab 这个平台的整体免费额度，这一期专门把 CI/CD 这一块单独拆开讲——原因很简单：GitLab 的流水线是它最值钱的部分，也是免费额度里最容易被误算的部分。
你手上的资料基本方向是对的：共享运行器每月 400 分钟、私有/自托管运行器不限分钟、支持 Docker、支持并行构建和多项目流水线。这几项在官方文档里都能找到对应。
但这里面藏着一个关键机制，官方文档写得很清楚、而大多数教程都略过了：400 这把数字会被一个叫"成本系数"的乘数放大。官方给出的计算框架是——
单次作业消耗的计算分钟 = 作业时长（秒）÷ 60 × 成本系数
也就是说，"400 分钟"是按最小规格算出来的理想值。你一旦把运行器规格调大，它会等比缩水。 下面把这件事讲透。
一、先讲透机制：400 分钟是"额度单位"，不等于"墙上的时间"
1. 官方口径：Free 层级命名空间每月 400 计算分钟。
这一条明确无疑。官方文档原文："Free tier namespaces receive 400 compute minutes per month." 需要更多可以单独购买。
2. 关键在"成本系数"（Cost Factor）。
官方对成本系数的说明很直白："成本系数是一个乘数，用来设定作业消耗计算分钟的速度。它不是货币价格。" 系数取决于 运行器类型 + 项目类型。
按官方文档给出的 GitLab.com 托管运行器成本系数表：
这张表解释了几件很实际的事：
默认的 Linux small 系数是 1——所以你听说的"400 分钟"，是按默认最小规格算的，这个数字本身没错；
但只要升级规格，额度就等比缩水。用 large 就是 3 倍消耗，实际只剩约 133 分钟；想并行编译提速、上 2xlarge，400 分钟只够撑 33 分钟；
Windows medium 的系数是 1（测试版），这一点和 GitHub Actions 的 2 倍扣费不同，在 GitLab 上跑 Windows 并不比 Linux 贵；
macOS 是最贵的：M1 medium 系数 6，M2 Pro large 系数 12，和 GitHub 的 macOS 10 倍扣费属于同一量级。
3. 还有"项目类型"这个维度。
官方还明确了按项目类型的折扣：公开项目的成本系数为 0（不消耗计算分钟），内部和私有项目为 1。
对使用者的意义是：如果你参与 GitLab 维护的开源项目，或者你的项目是公开的，那部分消耗不计入配额。 这对开源贡献者算是个实打实的利好。
4. 计时起点也有讲究：从 created / pending 状态出来的时长不算。
官方说明："作业时长"指的是作业运行所花的时间（秒），不包括处于 created 或 pending 状态的时间。
也就是说，共享运行器排队等待的时间不计费——这对免费用户是个好消息。但反过来也提醒你：排队虽然不花钱，但它消耗的是你的时间，高峰期共享运行器排队十几分钟是常态。
二、自托管运行器：这才是真正的"无限分钟"
你资料里"私有/自托管运行器无限分钟"这一条，方向完全正确，但机制值得说清楚——因为它是 GitLab 免费层最重要的一根"扩容杠杆"。
官方文档有两处直接说明：
"项目运行器（Project runners）不受计算配额约束。" ——项目级的自托管运行器不计入那 400 分钟，跑多久都不扣额度；
成本系数只适用于"管理员管理的实例运行器"——也就是说，你自己注册的、挂在项目或组下的运行器，不适用成本系数这套计算。
所以准确的说法是：自托管运行器在 GitLab 侧是"零成本、不计量"的。 你可以把它理解成——把那 400 分钟这道闸门直接绕过去，代价是自己出机器。
但要注意三件事：
"免费"指的是 GitLab 不收费，不是真的不花钱。 服务器、电费、带宽、维护时间都是你的成本。
公开项目用自托管运行器有安全风险。 别人可以提 PR 让你的流水线在他们的代码上跑——恶意 PR 可能在你的机器上执行任意命令。这是自托管运行器的经典坑，公开仓库务必谨慎，或只跑受信任的分支。
每个项目最多注册 50 个运行器（上一期核实过的限制），够用但不是无限。
三、逐项核实：免费 CI/CD 的完整能力清单
除了分钟额度，GitLab 免费层的 CI/CD 能力覆盖面如下：
Docker 支持（完整）
三层能力都给：用
image:指定作业运行的容器镜像——这是 GitLab CI 最常见的用法，环境隔离靠它；用
services:起依赖服务——比如跑集成测试时临时拉一个 PostgreSQL、Redis 容器，不用自己装；构建并推送容器镜像到 GitLab 自带的容器注册表（
registry.gitlab.com），这部分存储不计入项目的 10 GiB 仓库配额。并行构建：
parallel与parallel:matrix
parallel关键字可以把同一个作业拆成多个实例并行跑，适合把测试用例分组执行；
parallel:matrix 做多维度组合（比如PROVIDER: [aws, gcp]×STACK: [monitoring, app1, app2]一次生成 6 个作业），是跨平台、跨版本矩阵测试的标准写法；官方文档显示，矩阵表达式（Matrix expressions）在 GitLab 18.6 引入，支持在
needs:parallel:matrix里做 1:1 的动态依赖映射，不用再手工罗列所有组合。用新版能少写不少 YAML。注意：并行会成倍消耗计算分钟——6 个矩阵作业就是 6 份消耗，这是很多人额度"突然不够用"的原因。
多项目流水线（Multi-project pipelines）
一个项目的流水线可以触发另一个项目的下游流水线，适合微服务架构下"改了公共库、自动触发下游服务构建"这种场景；
可以指定下游流水线的 ref 并传递 CI/CD 变量给它；
权限前提：触发者必须有权在下游项目里启动流水线，否则下游流水线起不来；
默认流水线层级最多 1000 条下游流水线；
父子流水线（parent-child）最多嵌套两级；多项目流水线是独立的，没有嵌套限制。
触发作业不消耗计算分钟（一个实用的隐藏福利）
官方明确写着：触发作业（trigger jobs）不在运行器上执行，所以不消耗计算分钟——即使使用了strategy:depend等待下游流水线状态，触发作业本身依然不计费。真正计费的是被触发的下游流水线。
这意味着：搭多项目流水线架构时，"调度层"是免费的，你只需要为实际干活的作业付额度。社区贡献者的额外额度
为 GitLab 维护的开源项目做贡献时，最多可在实例运行器上使用 300,000 分钟。公式是"月度计算配额 ÷ 300,000 = 成本系数"——例如 Pro 层月度配额 10,000 分钟时，系数约为 0.0333。这个数字对开源贡献者来说几乎等于"用不完"。免费额度按自然月重置
官方说明：计算分钟用量每月归零，配额重置为月度分配量，同时保留上个月的数据用于历史查看。
四、超额后会怎样：有 1,000 分钟的宽限期
这是本次核实中一个很实用的发现，官方写得很具体：
当本月配额用尽时：
实例运行器停止处理新作业；
已经启动的流水线里，排队中（pending）或重试的作业会被丢弃；
已经在运行器上跑的作业可以继续跑——直到该命名空间超出配额 1,000 计算分钟，这个宽限期过后，还在跑的作业也会被丢弃。
注意最后这一条：它不是"超额即断"，而是给了 1,000 计算分钟的缓冲。也就是说，你的作业不会在跑到一半时被突然掐断，但缓冲用完就真的停了。
通知机制也很清楚。剩余额度降到以下水平时，会同时弹应用内横幅 + 给命名空间所有者发邮件：
剩余不足 25%
剩余不足 5%
完全用尽（0 分钟）
而且项目和组的自托管运行器不受这个配额影响——配额只管实例运行器（也就是 GitLab 托管的那种）。
五、实测踩坑：这几条一定要提前确认
结合起来看，GitLab CI/CD 免费额度的坑集中在"系数放大"和"运行器选择"两处。
别再按"400 分钟"估工作量，先看你的运行器规格。 默认 small 系数 1，确实是 400 分钟；但用 medium 就变 200、large 变 133。升级规格是为了提速，代价是额度等比缩水——这是最需要权衡的一点。
矩阵构建会成倍吃额度。
parallel:matrix生成几个作业就几份消耗。做多平台测试前，先算一下组合数乘上单次时长，看看 400 分钟够不够。自托管运行器是唯一的"无限"路径，但要自己扛机器和安全。 公开项目尤其要小心陌生 PR 的执行风险。
Pages 部署会消耗计算分钟。 如果你用 GitLab Pages 托管博客，每次部署都是一次流水线——给 Pages 作业加上分支限制（只在主分支触发）能省不少。
排队不计费，但会拖时间。 共享运行器在高峰期排队是常态，如果构建紧急，自托管运行器还能顺带解决排队问题。
触发作业不花钱，可以放心搭多项目架构。 这一条对微服务团队特别有用——调度层免费，只为主力作业付费。
先确认你的项目是公开还是私有。 公开项目成本系数为 0、不消耗计算分钟；私有项目按正常系数计。如果你的项目本来就可以开源，把它转成公开能直接省掉这部分额度。
额度耗尽后作业是被"丢弃"，不是失败重试。 排队中的作业直接扔掉，要重新触发。盯紧 25% 和 5% 那两封提醒邮件很关键。
六、实操：从零到跑通一条流水线
第一步：启用 CI/CD
项目里新建 .gitlab-ci.yml 放仓库根目录，push 后自动触发。GitLab 会识别这个文件并创建流水线。
第二步：定义阶段与作业
用 stages 声明阶段（常见的 build → test → deploy），每个作业用 stage 归到对应阶段。同一个阶段的作业默认并行执行。
第三步：用 image 指定运行环境
比如 image: node:20-alpine、image: python:3.12，环境隔离靠它。需要数据库等依赖时用 services: 起容器。
第四步：按需选运行器规格
这一步直接决定消耗速度。默认走 small（系数 1），需要提速可以选大规格，但要接受额度缩水。tags 可以用来把作业定向到指定的运行器。
第五步：配置缓存与制品
cache：缓存node_modules、.m2、vendor这类依赖目录，避免每次重新下载——这是省时间最直接的一招，也间接省额度；
artifacts：传递构建产物到后续阶段。记得设 expire_in（比如1 week），别让制品无限期堆积。
第六步：设置触发规则
用 rules 控制作业什么时候跑。给部署和 Pages 类作业加上分支限制，避免每次推送都触发全量流水线。
第七步：盯住用量
在「组 → Settings → Usage Quotas → Pipelines」里查看当月计算分钟消耗和剩余。收到 25% / 5% 提醒邮件时就要开始做取舍了。
七、壹贰线报专属：两套务实方案
个人 / 开源项目方案（免费层最合适）
如果项目是公开的，成本系数为 0，实例运行器的消耗基本可以忽略——这是 GitLab 免费 CI/CD 最划算的用法，开源项目可以放开跑矩阵和多阶段流水线。私有项目则要精打细算：坚持用默认 Linux small（系数 1），把 400 分钟留给真正必要的构建；依赖全走 cache；矩阵只在打 tag 时触发；Pages 部署限定主分支。这套方案零成本，适合个人博客、开源库、小型工具项目。
团队 / 微服务方案（用自托管撬开上限）
如果构建量大，自托管运行器是性价比最高的选择——GitLab 侧不计费，只要能提供一台机器。配套的做法是：用多项目流水线把服务串起来（触发作业免费，只为主力构建付费），基础构建走共享运行器、核心服务走组级自托管运行器、特殊环境需求走项目级运行器。这套架构下，400 分钟的免费额度基本只是"备用"，不用担心撞线。唯一要额外投入的是机器维护和运行器安全。
需要提醒的是：上一期核实过的几项限制同样适用——私有顶级命名空间最多 5 个用户、每项目仓库 + LFS 合计 10 GiB、2026 年 1 月 27 日后新建账号顶级组最多 3 个，以及 2026 年 10 月 19 日生效的流量限流（Free 层已验证请求每小时 5000 次、未验证请求每小时 60 次）。如果你的自动化脚本在调 GitLab API，记得带上访问令牌做验证，否则会按未验证流量算，额度低得多。
最后提示
壹贰线报只发核实过的信息。GitLab CI/CD 这一块最值得说的，是它的免费额度不是"给时间"，而是"给算力"——官方把计量单位改成了"计算分钟"，再乘一个随规格浮动的成本系数。这个设计不会限制你用功能，但会让你对"我还剩多少"产生明显误判：默认规格下是 400 分钟，用大规格就只剩三分之一。
上手前建议想清楚四件事：一是项目是公开还是私有，这决定要不要精算；二是运行器选什么规格，系数直接决定额度缩水多少；三是要不要自托管运行器，它是把 400 变成"无限"的唯一路径；四是有没有矩阵和多项目架构，这两项都会成倍消耗。