关键在于清理本地悬空镜像、未引用镜像层、构建缓存、日志文件和孤立卷；需分阶段执行docker image prune（悬空）、docker image prune -a（未被引用的带标签镜像）、docker system prune（容器/网络/缓存等），生产环境慎用--volumes。
清理容器镜像仓库的磁盘空间，关键不是删远程 Registry（比如 Docker Hub 或 Harbor），而是处理本地或私有仓库节点上那些“看不见却占地方”的残留数据：悬空镜像、未被引用的镜像层、构建缓存、日志文件和孤立卷。这些才是长期运行后磁盘告急的真正元凶。
识别两类真正可安全清理的镜像
Docker 分层共享机制决定了不能按名字乱删——误删基础层可能让多个镜像失效。真正能放心清理的只有：
-
悬空镜像（dangling images）：镜像 ID 存在，但仓库名和标签都是
<none></none>。常见于重复执行docker build -t app:latest或docker pull后旧版本失去标签。 -
未被任何容器引用的镜像：有明确标签（如
nginx:1.25），但当前没有运行中或已停止的容器在使用它。这类镜像不会自动回收，会一直躺在/var/lib/docker里吃空间。
分阶段执行精准清理命令
从低风险到高风险逐步推进，避免一步到位导致服务中断或数据丢失：
- 只清悬空镜像（最安全）：
docker image prune -f - 清所有未被容器使用的镜像（含带标签的闲置镜像）：
docker image prune -a -f - 一键清理停止容器、未用网络、悬空镜像、构建缓存：
docker system prune -f - 全量清理（含未挂载卷）：
docker system prune -a -f --volumes—— 生产环境慎用，务必确认卷中无业务数据
用 --filter 实现定向清除
避免“一刀切”，尤其适合多项目共存或 CI/CD 环境：
- 只删 48 小时前的悬空镜像：
docker image prune -f --filter "until=48h" - 只删某应用的历史镜像：
docker image prune -a -f --filter "reference=myapp:*" - 组合筛选（指定镜像 + 时间）：
docker image prune -a -f --filter "reference=redis:alpine" --filter "until=72h"
别忽略构建缓存与容器日志
这两类常是长期运行系统磁盘耗尽的隐藏主力：
-
构建缓存：用
docker builder prune -f清理；加-a清全部；加--keep-storage 2g可限制缓存上限。 -
容器日志：默认 JSON 日志不轮转，单个文件可能涨到几 GB。建议在
daemon.json中配置日志驱动参数："log-driver": "json-file",<br>"log-opts": {"max-size": "10m", "max-file": "3"}
