Docker镜像仓库GC必须手动触发且需停服，无法边运行边清理；应通过监控磁盘水位或标签增长动态触发，优先每日在线清理旧标签，再按需每周离线执行GC。
Docker 本身不提供“自动定时 GC”的内置服务，镜像仓库（如官方 Registry）的垃圾回收（GC）必须手动触发，且不能在服务运行时安全执行。所谓“配置频率”，实际是通过外部调度（如 cron）+ 停服流程 + 清理策略组合实现的节奏控制。关键不是调高频率，而是让每次 GC 动作更轻、更准、更可控，从而平衡磁盘释放与系统可用性。
停服 GC 无法避免，但可压缩窗口期
GC 必须在 registry 完全无写入时运行，否则会跳过被临时引用的 blob，导致清理不彻底或失败。因此：
- 不要试图“边运行边 GC”——这是设计限制，非配置缺陷
- 把停服时间压到最短：先完成所有 manifest 删除（标记阶段），再停服务、执行 GC、立即重启
- 推荐将整个流程封装为脚本，从停服到恢复控制在 30 秒内（小规模仓库）或 2 分钟内（TB 级 NFS 存储需额外 sync）
按需触发比固定频率更合理
高频 GC（如每小时）反而增加风险和负载，真正需要的是“按空间水位或标签增长速率”动态触发：
- 监控
/var/lib/registry或存储后端磁盘使用率，超过 75% 时自动启动清理流程 - 统计某仓库新增 tag 数量，连续 24 小时超 20 个，则触发保留策略扫描+GC
- 使用
regctl repo ls --format '{{.Name}}: {{.Tags}}'快速评估仓库活跃度，避免对冷仓库空跑
GC 前的“标记”动作才是频率调控核心
GC 本身只清 blob，真正决定释放多少空间的是“删 manifest”这步。它可安全在线执行，且支持细粒度过滤：
- 用
regctl tag rm myreg/myapp:dev-20250401删除旧标签（自动解析 digest 并调 DELETE） - 结合
--filter "until=72h"或正则匹配（如dev-.*|test-.*）批量下线测试镜像 - 每日凌晨执行一次标签清理，比每周一次 GC 更有效——因为 GC 只收尾，不找目标
生产环境推荐节奏模板
| 场景 | 操作 | 频率 | 说明 |
|---|---|---|---|
| 标签清理（在线） |
regctl tag rm + regctl manifest delete
|
每日 02:00 | 删掉 72 小时前的 dev/test 标签，不中断服务 |
| GC 执行（离线） | docker stop registry && docker exec ... garbage-collect && docker start |
每周日 01:30 | 仅当磁盘使用率 >80% 或上轮 GC 释放空间 |
| 构建缓存治理 | docker builder prune --keep-storage 4g |
每日 03:00 | 防止本地构建缓存膨胀干扰 registry 负载 |
不复杂但容易忽略。
