Docker镜像清理核心是将清理时机、范围、安全对齐业务节奏；CI后用docker-compose down --rmi local，流水线末尾用docker builder prune -f与docker image prune -f，定时巡检用docker system prune -a -f --volumes加until过滤，私有仓库需配置Retention Policy。
docker 镜像清理自动化运维，核心不是堆砌工具，而是把“清理时机、清理范围、清理安全”三者对齐业务节奏。真正有效的方案往往轻量、可嵌入、可验证，而非依赖重型平台。
明确清理目标再选命令
不同场景对应不同命令粒度，混用反而增加风险：
- CI 构建后立即清“本次产物” → 用
docker-compose down --rmi local（只删本项目本地构建、未打标签的镜像） - 流水线末尾清“全局残留” → 用
docker builder prune -f（清构建缓存） +docker image prune -f（清悬空镜像） - 定时巡检清“历史冗余” → 用
docker system prune -a -f --volumes（慎用，建议加--filter "until=72h"限定时间范围）
按标签策略批量清理需防误删
直接 docker rmi 删除标签有风险——同一镜像ID可能被多个标签共用。推荐先查后删：
# 查看 myapp 的所有标签，按创建时间倒序（需 docker 24.0+）
docker images myapp --format '{{.CreatedAt}}\t{{.Tag}}' | sort -r | head -n 5
# 保留最新3个，删其余（安全写法：先 echo 再替换为 docker rmi）
docker images myapp --format '{{.Tag}}' | sort -V | head -n -3 | xargs -r echo docker rmi myapp:私有仓库清理不能只靠本地命令
本地 docker rmi 只删本地镜像引用，不影响远程仓库。Harbor 等企业级仓库需配置 Retention Policy：
- 按标签正则匹配（如
^dev-.*） - 按拉取/推送时间保留（如 “最近7天内被拉取过的镜像不删”）
- 按镜像是否被 Kubernetes Pod 引用（需对接集群 API）
清理脚本必须带验证环节
自动化脚本最后一行建议加上空间检查：
# 清理后输出磁盘节省量（单位 MB）
echo "Disk freed: $(($(docker system df -v | awk '/Space Reclaimed/{print $4}' | sed 's/M//') - $(docker system df -v | awk '/Space Reclaimed/{print $4}' | sed 's/M//' | head -1))) MB"本质上，清理不是技术难题，而是流程卡点。把 docker image prune 嵌入 CI 的 post-build 阶段，比写一个“智能清理平台”更能解决 80% 的磁盘爆满问题。
