镜像版本回收机制需配置标签生命周期策略、启用垃圾回收及源头治理。harbor保留最新5个标签和stable/latest标签，ecr用json定义语义化版本保留规则；必须启用gc清理孤儿层；ci中删除临时标签、统一构建参数并定期升级基础镜像；通过存储用量、标签数量和日志验证效果。
直接配置镜像版本回收机制，核心是让仓库自动识别并删除无用标签和未被引用的层，而不是等空间告急才手动处理。关键不在“删多少”，而在“留什么”——保留真正需要的，清理明确可弃的。
设置标签生命周期策略
标签是镜像版本管理的入口，也是存储膨胀的主因。不加约束的自动打标（如 commit-hash、timestamp）会快速堆积无效副本。
- 在 Harbor 中，进入项目 → 策略 → 新建保留策略：勾选“保留最新5个标签”+“保留含 stable/latest 的标签”+“删除30天未拉取的镜像”
- 在 AWS ECR，使用 Lifecycle Policy JSON 定义规则，例如保留最近10个带语义化版本号（v\d+\.\d+\.\d+）的镜像，其余自动过期
- 避免依赖 latest 标签做部署——它不指向固定版本，会导致旧镜像无法被策略识别为“已弃用”
启用仓库级垃圾回收（GC）
删除标签只是移除清单引用，底层镜像层仍留在存储中。真正的空间释放靠垃圾回收扫描并清理这些“孤儿层”。
- 原生 Docker Registry：停服后执行 docker exec registry bin/registry garbage-collect /etc/docker/registry/config.yml
- serverless-registry：调用 API 触发 untagged 模式，同时清理无标签清单和未被引用的层
- Harbor：后台任务默认启用 GC，可在“系统管理 → 配置管理 → 垃圾回收”中调整触发周期与模式（推荐“立即执行 + 每日凌晨”）
结合构建流程做源头治理
再强的回收机制也比不上不产生冗余。把清理逻辑前移到 CI 流程中，效果更可控、成本更低。
- GitLab CI 或 GitHub Actions 中，在推送镜像后立即调用仓库 API 删除前一次构建的临时标签（如 pr-42、dev-commit-abc123）
- 构建时统一使用 --build-arg BUILD_VERSION=$(git describe --tags)，避免生成不可追溯的随机标签
- 基础镜像定期升级并重建所有衍生镜像，旧基础层失效后，GC 才能安全回收其上所有依赖层
监控与验证回收效果
不验证的策略等于没设。定期确认回收是否真正生效，避免规则配置错误导致“假清理”。
- 对比执行 GC 前后 R2/S3 存储用量，或 Harbor 控制台中的“存储使用量”图表
- 用 curl -s http://registry/v2/myapp/tags/list | jq '.tags | length' 统计标签数量变化
- 检查日志：Harbor 的 job_service 日志中搜索 garbage_collection，确认任务状态为 success
