各位站长、开发者，今天给大家带来一期逐项核对过 GitLab 官方文档的线报。
GitLab 是 DevOps 圈子里"全家桶"味道最足的一家：代码托管、CI/CD、Pages 静态托管、容器注册表、包注册表、Issue 看板、代码审查，全都在一个平台里，而且是唯一一家把整套产品完整开源的厂商。对个人开发者和小团队来说，gitlab.com 的免费版一直是个实在选择——公开和私有仓库都能建，CI/CD 开箱即用，Pages 直接出站。
但 GitLab 的免费政策也有它自己的脾气：限制卡在"人和存储"上，而不是卡在仓库数量上。而且它在 2026 年刚动过两次规则——一次是新账号的组数上限，一次是 10 月 19 日刚生效的流量限流。
下面我把核实后的情况讲清楚，其中有三处需要更正或澄清你手上的资料。
先说三处：5 人限制的范围、Pages 带宽、400 分钟
更正一：5 人限制只管"私有顶级命名空间"，不是所有账号。
"最多 5 名协作者"这个说法方向对，但边界必须说清，否则很容易误判自己的账号能不能用。
按 GitLab 官方文档口径，每个新建的、私有可见性的顶级命名空间，最多只能有 5 个用户。超过这个数，该命名空间会被置为只读状态——不能往仓库、Git LFS、包、注册表写入任何新数据。
但下面这几类不受这个限制：
公共顶级组（公开的开源项目）——不受限；
个人命名空间——因为默认就是公开的，也不计入；
自管理（Self-Managed）的 Free 层——完全没有用户数限制；
参与 GitLab for Open Source / Education / Startups 等社区计划的账号。
还有一点要注意：这个 5 人是按"命名空间里的唯一用户数"算的，组、子组、项目里的所有成员都会计入，不是每个项目单独 5 人。
更正二：GitLab Pages 的"无限带宽"说法不准确。
这一点需要如实说明：GitLab 官方文档并没有承诺 Pages"无限带宽"。
官方给的是这样一组明确参数：
单个 Pages 站点最大 1 GB（这个上限实际取决于 CI/CD 产物的大小限制）；
每个站点最多 150 个自定义域名；
每个站点最多 200,000 个文件（含目录和符号链接）；
以及请求速率限制：单个 IP 每 50 秒最多 1,000 次请求；单个 Pages 域名每 10 秒最多 5,000 次请求；TLS 连接也有对应限制。
官方并未公示 Pages 的月度流量配额数字。所以更准确的表述是：Pages 在正常个人站点场景下基本不用担心流量，但它不是条款意义上的"无限带宽"，而是有速率和体积约束的。网上那些"无限带宽"的说法，建议打个问号。
另外还有一条很多人忽略的：GitLab Pages 是靠 CI/CD 构建发布的，每次部署都会消耗你的计算分钟额度。所以你的 400 分钟里，有一部分是被 Pages 部署吃掉的。
澄清：400 分钟是准确的，但计算方式有讲究。
"每月 400 分钟共享运行器"这一条和官方口径一致——Free 层命名空间每月获得 400 计算分钟（compute minutes）。但它的计费不是简单的"跑一分钟扣一分钟"。
官方公式是：单次作业消耗 = 作业时长 ÷ 60 × 成本因子。不同的 runner 类型和资源规格有不同的成本因子，比如 Windows、macOS 或者更大规格的 runner 会按更高倍率扣分钟。也就是说，同样跑 10 分钟，用标准 Linux runner 和用 macOS runner，扣掉的额度完全不同。
另外还有两条实用规则：一是购买的计算分钟可以结转到下个月，未用完的部分不会作废；二是共享 runner 在高峰期会排队，这可能是比额度更早遇到的问题。
逐项核实：免费版到底给了什么
按 GitLab 官方文档，GitLab.com Free 层的完整情况如下：
仓库数量：不设明确上限
这一点你给的信息是准的——GitLab 官方没有规定"最多建多少个仓库"。但真正约束你的是存储：每个项目的 Git 仓库 + LFS 合计 10 GiB 免费存储，超过后该项目被置为只读，无法再推送。
这里要更正一个流传很广的旧口径：早期（2022 年）GitLab 曾按"命名空间 5GB"来做存储限制，现在的官方口径是"每项目 10 GiB"，两者不一样，别按老数字估容量。容器注册表、包注册表、构建产物：不计入 10 GiB 限制
这是免费层里少见的"好消息"，而且常被忽略。官方明确写着：只有项目的仓库和 LFS 计入存储限制，容器注册表（Container Registry）、包注册表（Package Registry）和构建产物（build artifacts）都不计入。
也就是说，把 Docker 镜像推到 GitLab 容器注册表、把 npm/Maven 包推到包注册表，不会占用那 10 GiB 仓库额度。对个人项目来说，这等于多了一份可用的存储空间。容器注册表（registry.gitlab.com）
完整的 Docker 镜像仓库能力，支持推拉镜像、与 CI/CD 流水线集成。官方对 Free 层没有单独公布存储配额（因为它不计入 10 GiB），但要注意 CI/CD 中拉取镜像会消耗任务时长。包注册表（Package Registry）
支持 npm、Maven、PyPI、NuGet、Conan、Helm、Terraform Module、Generic 等多种包类型。各类型有单文件大小限制，按官方实例配置表：Conan / Maven / PyPI 为 3 GB，Terraform Module 为 1 GB，Generic 为 5 GB，npm / NuGet 为 500 MB，Helm 为 5 MB。做包分发前先对照一下，别传了才发现超限。CI/CD：每月 400 计算分钟 + 共享 runner
这一条和你给的一致。Free 层还有几项配套限制值得知道：单条流水线最多 500 个作业，活跃流水线中的作业数上限也是 500；
每个项目的流水线计划最多 10 个，每个计划每天最多触发 24 条流水线；
Artifacts 单份最大 1 GB（压缩后），默认保留 30 天，过期自动清理；
每个 group / 项目最多注册 50 个 runner；
dotenv 变量 Free 层上限 50 个。
Issue、看板、Wiki、代码审查
这几项你给的信息准确。Free 层包含 Issue 追踪、看板（Board）、Wiki、Merge Request 代码审查、里程碑、标签体系等完整协作功能。GitLab 的 Merge Request 流程做得比较克制但完整，代码评审、多轮讨论、审批都在同一处。
需要说明的是，Free 层不含高级安全测试能力（比如依赖扫描、SAST 的完整功能、安全看板），那些属于 Ultimate 层。私有仓库与团队协作
私有仓库本身免费建，但要受前面说的 5 用户限制约束——私有顶级命名空间超过 5 人就会变只读。
一条刚生效的新规：2026 年 10 月 19 日起限流
这是本文最需要提醒的时效信息，因为它就在十天前刚生效。
GitLab 官方在 9 月宣布，从 2026 年 10 月 19 日起调整 GitLab.com 的流量限制，按订阅方案分档。Free 方案和未验证请求先适用，Premium / Ultimate 计划于 2027 年 1 月跟进。
具体额度是：
Free 方案的已验证请求：每小时最多 5,000 次，每分钟上限 100 次；
未验证的请求：单个 IP 每小时最多 60 次——而新规之前，一般未验证流量的限制是每分钟 500 次，这个降幅非常大；
Premium：每小时 15,000 次、每分钟 1,250 次；Ultimate：每小时 25,000 次、每分钟 2,000 次。
有几个细节值得注意：
未验证的 Git HTTPS 流量不计入这 60 次，仍维持原有较宽松的限制；
自动化工具和 AI 代理即使访问付费方案下的资源，只要没带验证信息，也按未验证流量算；
开发者可以用个人访问令牌、OAuth 令牌或 CI/CD 作业令牌来验证请求，这样流量就按账号所属方案的额度走；
超限返回 HTTP 429 状态码，并带有 Retry-After 头，可以按提示等待后重试；
该调整只适用于 GitLab.com，自己搭建的 GitLab 和 GitLab Dedicated 不受影响。
这条新规的实际影响是：裸奔的脚本、爬取、匿名 API 调用会最先受影响。如果你有自动化脚本在访问 GitLab.com，建议尽早加上令牌验证。
还有一条容易忽略的：新账号只有 3 个顶级组
官方文档里还有一条 2026 年新加的限制：2026 年 1 月 27 日之后创建的 Free 层账号，最多只能有 3 个顶级组（group namespace）——个人命名空间不计入。想建更多组需要升级付费层。
对习惯"一个项目一个组"的开发者，这条要提前规划。
实测踩坑：这几条一定要提前确认
结合起来看，GitLab 免费版的坑集中在"限制卡在特定条件下"这一特点上。
5 人限制只在私有顶级命名空间生效，但一旦触发是"只读"。 不是提醒、不是限速，而是直接不能写。如果你的私有组已经接近 5 人，建议提前确认成员列表（在组的 Settings → Usage Quotas → Seats 里能看到）。
存储限制是"每项目 10 GiB"，不是命名空间总的 5GB。 别拿 2022 年的旧文章估容量。
仓库体积超限是只读，不是停止付费服务。 超 10 GiB 后无法推送，但可以正常读取和克隆——这也是它相对温和的地方。
Pages 部署要消耗 CI 分钟。 如果你用 Pages 做博客、推送频繁，那 400 分钟会很快被吃掉。建议给 Pages 的流水线加限制条件（比如只在主分支触发）。
共享 runner 会排队，额度不等于能立刻跑。 高峰期等十几分钟是常态，这也是很多人转向自建 runner 的原因——自建 runner 不计入这 400 分钟，只需要自己承担机器成本。
新账号顶级组只有 3 个。 建项目前先想清楚组织结构，别等建到第 4 个才发现。
国内访问速度需要实测。
gitlab.com走的是海外节点，clone、push 的体验和国内平台差异明显，面向国内的协作项目建议先评估。GitLab 的免费口径这几年一直在收紧。 从 2022 年的命名空间存储限制、到 5 用户上限、到 2026 年的 3 组上限和限流新规，是一条清晰的收紧曲线。重要项目建议留好迁移方案（Git 原生可迁移性最好，这点不用太担心）。
实操：从零到上线的完整流程
第一步：注册并确认命名空间形态
GitLab.com 注册后默认会有一个个人命名空间（公开、不计入 5 人限制）。如果要建私有协作组，注意 5 人上限和 3 个顶级组的约束。
第二步：创建项目并推送代码
支持 HTTPS 和 SSH 两种方式。注意单次推送上限 5 GiB，附件单文件上限 100 MiB，大文件建议走 LFS。
第三步：配置 CI/CD
在项目根目录写 .gitlab-ci.yml 定义流水线阶段。Free 层用共享 runner，每月 400 计算分钟；如果构建频繁，建议注册自建 runner（每项目最多 50 个）。
第四步：用 Pages 发布站点
在 CI 配置里加一个 Pages 部署作业，构建产物放进 public 目录。上线后是 用户名.gitlab.io/项目名 的地址，支持绑定自定义域名（每站点最多 150 个）并自动签 TLS 证书。
第五步：推镜像到容器注册表（可选）
用 docker login registry.gitlab.com 登录后推送。这部分不计入 10 GiB 仓库存储限制，可以放心用。
第六步：盯住用量页面
在组的 Settings → Usage Quotas 里可以查看存储占用、席位（Seats）和流水线用量，其中存储用量每 90 分钟更新一次。这是避免"某天突然推不上去"最有效的习惯。
壹贰线报专属：两套务实方案
个人开发方案（免费层最合适）
用一个私有组装个人项目，成员控制在自己（或 1–2 人）以内，避开 5 人红线。代码托管 + CI/CD 用共享 runner，把构建逻辑做轻，400 分钟对个人项目够用；Docker 镜像推容器注册表、npm 包推包注册表（都不占 10 GiB 仓库额度）；需要展示站点就用 Pages，注意加好触发条件别浪费 CI 分钟。这套方案没有服务器、没有额外支出。
小团队协作方案（要看人数）
如果团队在 5 人以内，免费版的完整 DevOps 链路（Issue → 分支 → MR → 代码审查 → CI/CD → 部署）可以直接跑起来，一站式体验是它的最大优势。一旦超过 5 人，私有组会变只读，这时要么升级 Premium（含 10,000 计算分钟/月），要么把项目转为公开组（不受用户限制），要么把代码托管换到不限制协作者人数的国内平台。团队规模是 GitLab 免费版最硬的那道门槛，选型前务必先数人。
最后提示
壹贰线报只发核实过的信息。GitLab 免费版有个鲜明特点：它给的功能很全，但限制都藏在具体条件里——5 人限制只管私有顶级命名空间、存储限制只管仓库和 LFS、Pages 做得很好但并不承诺"无限带宽"。搞清楚这些边界，就能判断它到底能不能承载你的项目。
上手前建议想清楚四件事：一是团队人数，5 人是硬门槛；二是仓库体积，10 GiB 是每项目的天花板；三是构建频率，400 分钟会被共享 runner 和 Pages 部署一起消耗；四是面向国内还是海外协作，访问速度的差异很明显。
有在用 GitLab 的朋友，欢迎在评论区说说你的用量情况——特别是共享 runner 排队和 Pages 部署消耗 CI 分钟这两件事，有没有影响到你，和其他开发者一起交流经验。