Docker Hub、GHCR、Quay 怎么选：团队场景的选型对照（可持续更新）

公开镜像 Registry 很多，团队最难的不是「能不能用」，而是十年后还好不好维护。本文提供四维对照：权限与协作模型、CI 集成与开发者体验、速率限制与稳定性成本、运维与迁移成本。

说明：公开服务的配额与条款会变化，本文用于方法论；上线请以官方文档为准并定期复核。

1. Docker Hub：生态默认，但要正视速率限制

Docker Hub 往往是第一反应：示例最多、教程最全。对团队的含义是：上手成本低，但在规模化 CI/CD 场景需要正视匿名/登录拉取的配额差异。

适用：

• 开源项目与公共基础镜像消费
• 需要最广兼容性与示例生态

注意：

• 高频拉取时要提前规划登录、镜像缓存或私服汇总

2. GHCR：跟 GitHub 协作链路天然耦合

如果你的源码、流水线、发布权限已经在 GitHub / GitHub Actions 生态内，GHCR 往往能减少「权限分裂」。但要注意：Packages 权限模型与仓库权限并非天然完全一致，需要在组织层面一次性梳理清楚。

适用：

• GitHub 为核心的研发组织
• 镜像发布与版本治理希望贴近仓库权限

3. Quay：更强的镜像仓库治理能力（团队观感）

不少团队选择 Quay 的原因集中在命名空间、机器人账号与合规治理能力（观感因版本与部署形态而异）。如果你们已经有明确的「镜像治理流程」，Quay 常在候选名单中。

适用：

• 更强调镜像治理与组织级策略的团队（结合具体部署）

4. 迁移成本：不要等到被迫迁移才考虑

团队最常犯的错误是：先在 A Registry 跑一年，发现配额与权限不满足，再迁移到 B。迁移涉及的不仅是镜像搬运，还包括：

• CI 变量与密钥
• K8s Secret 与命名规范
• 历史版本的镜像仍可追溯（digest）

5. 小结

选型先看协作与安全边界，再看配额与成本，最后才看「是否顺手」。把这篇当作索引：每年复核一次条款与配额，比一次性争论更有意义。