定期清理废弃镜像需结合策略、权限、依赖与自动化，核心是识别既未被容器引用又无业务或安全保留需求的“真无用”镜像，涵盖悬空镜像、过期测试镜像、含高危漏洞旧镜像等，并通过docker image prune、私有仓库api及自动化脚本分级清理。
定期清理废弃镜像不是“删完就走”的操作，而是需要结合策略、权限、依赖和自动化的一套运维习惯。核心在于识别“真无用”——即既未被任何容器引用、也无业务或安全保留需求的镜像。
明确哪些镜像算“废弃”
废弃镜像通常具备以下一个或多个特征：
- 标签含 test、dev、feature/、日期后缀（如
v1.2.3-20250401）且超过 30 天未拉取或使用 - 未被任何运行中或已停止的容器引用（
docker ps -a --format '{{.Image}}'可比对） - 属于悬空镜像（
<none>:<none></none></none>），即无仓库名和标签，多为构建中间层残留 - 基础镜像存在已知高危漏洞（如 CVE-2025-xxxx），且对应应用镜像已升级但旧版未下线
本地镜像清理：用好 docker image prune
这是最常用也最安全的批量清理方式，无需手动解析 ID 或写脚本：
- 清理所有悬空镜像（推荐每天执行）：
docker image prune -f - 清理所有未被容器引用的镜像（含带标签的）：
docker image prune -a -f - 按时间过滤（例如删 7 天前未使用的）：
docker image prune -a -f --filter "until=168h" - 按条件组合（如删所有 test 标签且 14 天前创建的）需配合脚本，但建议先用
docker images --filter "before=nginx:latest" -q筛选再处理
私有仓库（如 Harbor、Nexus）清理
这类仓库不响应 docker rmi，必须走 API 或 Web 控制台：
- Harbor：调用
DELETE /api/v2.0/projects/{project}/repositories/{repo}/artifacts/{tag}，删除后务必手动触发垃圾回收（GC） - Nexus：在 UI 的 Repository Browser 中定位到镜像 → 右键 Delete；或通过 Nexus REST API 删除特定 tag
- 通用建议：优先通过 UI 批量选择标签删除，避免误删整个仓库；生产环境操作前导出 tag 列表留痕
建立自动化清理机制
靠人工容易遗漏，推荐落地两级自动化：
-
每日轻量清理：crontab 执行
docker image prune -f和日志轮转（journalctl --rotate --vacuum-time=7d） -
每周深度清理：运行自定义脚本，例如统计各仓库镜像数量、按标签匹配规则（如
.*-snapshot）、检查 last-pulled 时间（需开启 registry 的 prometheus metrics 或启用 harbor 的审计日志） - CI/CD 流水线中嵌入清理步骤：在镜像推送成功后，自动触发对同仓库下旧版本（如非
prod-前缀）的过期镜像清理
不复杂但容易忽略的是：清理后要验证存储释放效果（du -sh /var/lib/docker）、确认关键服务镜像仍可正常拉取，并把清理逻辑纳入团队文档或 SOP。
