关键在于建立可执行、不伤业务的镜像清理节奏，重点是明确“哪些该留、哪些该走、什么时候动手”；优先清理悬空镜像、旧版本镜像和临时/测试镜像，并配合自动化与资源协同治理。
直接删镜像不解决问题，关键在于建立可执行、不伤业务的清理节奏。重点不是“删多少”，而是“哪些该留、哪些该走、什么时候动手”。
明确哪些镜像该优先清理
不是所有镜像都值得保留。以下三类建议定期识别并清理：
- 悬空镜像（dangling images）：没有标签、也不被任何容器引用的中间层，纯属构建残留，无业务价值
- 旧版本镜像：比如 v1.0.0、v1.1.0 等已上线 v1.3.0 的旧版，尤其当本地不再调试或回滚时
-
临时/测试镜像：含
dev、test、feature/、tmp-等前缀或标签的镜像，通常生命周期短、易遗忘
用对命令，避免误删和卡死
不同场景对应不同命令，混用容易出问题：
- 日常清理悬空镜像：用
docker image prune—— 安全、默认只删无标签且无容器依赖的镜像 - 批量清理所有未使用镜像（含无标签+有标签但未运行）：用
docker image prune -a，加-f跳过确认 - 按名称或时间精准清理：比如删掉 7 天前的 nginx 测试镜像：
docker images --format "{{.ID}} {{.CreatedSince}}" | awk '$2 > 7 {print $1}' | xargs -r docker rmi - 强制删除被引用的镜像（慎用）：先
docker stop && docker rm相关容器，再docker rmi -f <id>
把清理变成自动化习惯
靠手动想起来删，90%会积压。推荐两个轻量级落地方式：
-
每周一早上自动执行：加一行 crontab（如
0 9 * * 1 docker image prune -f && docker container prune -f），只清停止容器 + 悬空镜像，零风险 -
构建后自动清理中间层：在
docker build命令中加--no-cache --rm参数，构建完立刻删掉中间容器和缓存层 -
开发脚本集成清理逻辑：比如每次
make up启动前，自动跑docker system df查空间，超 85% 就触发docker image prune -f
配合其他资源一起看，别只盯镜像
镜像常不是最大头——真正吃空间的往往是构建缓存、停止容器和未挂载卷：
- 查真实占用：运行
docker system df -v，它会分项显示镜像、容器、卷、构建缓存各自占多少 - 构建缓存可能比镜像还大：用
docker builder prune清理（Docker 23.0+ 默认启用 BuildKit） - 停止但未删的容器也占空间：
docker container prune -f比删镜像更立竿见影 - 数据卷容易被忽略：用
docker volume ls -q | xargs -r docker volume inspect | grep -q "Mountpoint" || echo "unmounted"辅助判断是否真闲置
