自动化镜像清理需策略性保留关键版本、淘汰冗余副本，核心是基于标签规则精准清理、按最后使用时间动态淘汰、利用原生命令兜底，并执行前验证引用关系、部署声明和仓库digest一致性。
自动化镜像清理不是“删得越狠越好”，而是有策略地保留关键版本、淘汰冗余副本。核心在于识别哪些镜像真正“已过期”或“未被使用”，而非简单按时间一刀切。
基于标签规则的精准清理
如果团队遵循规范的标签命名（如 v1.2.0、test-build-123、dev-abc123f），就能用正则或字符串匹配自动归类并清理：
- 删除所有 -test 或 -dev 标签的镜像（测试/开发镜像通常不需长期保留）
- 对主版本（如 v1.*）只保留最新 3 个修订版，其余自动下线
- 跳过带 prod-、stable- 前缀的标签，确保生产镜像不受影响
示例命令（配合 docker images --format 和 awk/sed）可提取符合模式的 IMAGE ID 后批量 docker rmi。
按最后使用时间动态淘汰
镜像是否“有用”，关键看它是否被容器引用过。Docker 本身不记录拉取/运行时间，但可通过以下方式补全：
- 启用 Docker daemon 的 experimental 功能后，部分版本支持 docker image inspect --format='{{.Created}}' 辅助判断
- 更可靠的做法是结合外部日志：从 CI/CD 流水线记录每次部署使用的镜像摘要（digest），定期比对，无部署记录且超 60 天的镜像标记为待清理
- 私有仓库（如 Harbor）自带 API 可查 pull_count 和 last_pull_time，直接调用 /projects/{proj}/repositories/{repo}/artifacts 接口筛选低活跃度镜像
利用原生命令做轻量级兜底
不依赖额外工具也能建立基础防线，适合中小规模环境：
- docker image prune -f --filter "until=720h"：清除 30 天内未被创建（即未被构建或拉取）的镜像
- docker image prune -f --filter "dangling=true"：一键清空悬空镜像（无标签、无容器引用）——这类镜像几乎一定可删
- docker system prune -f --filter "until=168h"：连带清理停止的容器、构建缓存和网络，防止资源碎片化
建议将上述命令封装为 cron 脚本，每周日凌晨执行，并将输出日志写入文件便于审计。
清理前必须验证的三件事
自动清理一旦出错，可能导致服务无法重建。执行前务必确认：
- 目标镜像是否被任何运行中或已停止的容器引用（docker ps -a --filter "ancestor=
" -q ） - 该镜像是否在 Kubernetes 清单、Helm Chart 或 GitOps 仓库中被显式声明（避免误删正在灰度的版本）
- 私有仓库中是否存在同名但不同 digest 的镜像（同一标签可能指向多个历史镜像，删错一个会影响回滚）
安全做法是先用 --dry-run 类参数模拟（部分工具支持），或先 docker tag 打上 to-be-deleted-202606 标签观察 24 小时，再批量清理。
