今天，我收到了一封 GitLab 发来的邮件，标题是《Important Change to Your GitLab.com Account》。内容很直白：GitLab.com 将不再为位于中国大陆、香港和澳门的个人及组织提供账户服务，账号需要在 2026 年 9 月 7 日前完成迁移，逾期会被删除。
邮件原文如下：
Please be advised that GitLab can no longer service GitLab.com accounts for individuals and organizations located in Mainland China, Macao, and Hong Kong. Our system indicates that you are visiting GitLab from one of these locations. We advise you to sign up with JiHu https://gitlab.cn/saasmigration/. JiHu is an independent company with a localized GitLab offering that has an exclusive right to provide GitLab to individuals and organizations located in this region. You must complete the transition by September 07, 2026, after which GitLab will delete your account from our systems. If you believe you are receiving this notification in error, please log in to GitLab.com from a supported service location. For further information or support, please feel free to contact saasmigration@gitlab.cn. Best Regards, GitLab Team
译文：
请注意，GitLab 已停止为位于中国大陆、澳门和香港的个人及组织提供 GitLab.com 账户服务。我们的系统显示您目前正从上述地区访问 GitLab。我们建议您注册极狐（https://gitlab.cn/saasmigration/）。极狐是一家独立公司，提供本地化的 GitLab 服务，并拥有为该地区个人及组织提供 GitLab 服务的独家授权。您必须在 2026 年 9 月 7 日前完成迁移，之后 GitLab 将从我们的系统中删除您的账户。如果您认为收到此通知有误，请从受支持的地区登录 GitLab.com。如有任何疑问或需要帮助，请随时联系 saasmigration@gitlab.cn。此致，GitLab 团队
这不是我第一次看到类似通知。早在 2024 年 12 月 22 日，我就写过《GitLab Global 国际站将在60天内删除中国大陆、香港、澳门地区的账号》。当时我在源代码里发现了相关提示：位于中国大陆、香港和澳门的个人及组织需要迁移到极狐 GitLab，限期 60 天，之后账号会被删除。
当时还以为只是一次短期调整，没想到两年后，这件事还是落到了自己头上。
说不失望是假的。GitLab 账号不只是放几份代码的地方，它也是参与开源协作的一张门票。账号没有了，提交 Issue（现在叫 Work Item）、发起 MR，甚至维护自己留下的项目，都会变得麻烦许多。
GitLab 过去也曾按地区限制服务
这类事情并非第一次发生，而且它并不只是“中国用户该怎么办”的话题。GitLab.com 作为美国公司的在线服务，长期需要处理出口管制和制裁合规；实际影响往往先落在普通开发者的登录、协作和数据访问上。
2018 年：迁移云平台前的公开提醒
2018 年 7 月，GitLab 宣布将 GitLab.com 从 Azure 迁移到 Google Cloud Platform。公告中特别提醒：由于 Google 所说的法律限制，位于克里米亚、古巴、伊朗、朝鲜、苏丹和叙利亚的用户，在迁移后可能无法访问 GitLab.com。GitLab 当时给出的建议也很朴素：先下载代码，或导出相关项目留作备份。GitLab 当年的迁移公告 至今仍能看到这段说明。
这件事值得注意的地方，不在于某个地区的名单有多长，而在于一次看似普通的基础设施迁移，也可能让服务的可访问范围发生变化。对用户来说，等到登录页打不开再想起备份，通常已经太晚。
规则会变，数据不能只放一处
GitLab 目前的贸易合规说明仍写明，其部分软件和服务受美国出口管制与制裁规则约束；页面列出的受影响国家和地区也会随法规调整而变化。它不是一张永远不变的“封禁名单”，但足以说明：把代码托管在云服务上，不等于获得了永久、无条件的访问权。
所以，本文收到的邮件并非完全孤立的事件，而是同一类合规风险在不同时间、不同地区的又一次落点。对个人开发者和小团队而言，最现实的应对并不复杂：仓库有本地副本，重要项目有可用镜像，协作数据能导出、能恢复。
别等到最后一天再处理
这封邮件至少提醒了我一件事：放在第三方平台上的代码和项目数据，不能只靠“平台应该还在”这件事来兜底。一旦账号被判定为受影响地区账号，留给你处理数据的时间可能并不多。
如果你也收到了这封邮件，建议先把这些事情做掉：
- 克隆并确认本地保留了所有重要仓库，别漏掉 Wiki、LFS 文件和 Release 附件；
- 导出项目中的 Issue、Work Item、Merge Request 等协作记录；
- 盘点 CI/CD 变量、部署配置、Webhook 和访问令牌。令牌不该直接写进备份文件，但要确认迁移后仍能重新配置；
- 根据团队实际情况，尽早确定迁移目标，并留出验证权限、流水线和镜像的时间。
最重要的不是临时赌一次地区判定，而是把属于自己的数据和协作记录先拿回来。代码可以迁，账号没了以后再补救，往往就没那么从容了。