关键在于清理本地镜像缓存、悬空镜像和未被引用的层：先用docker image prune删镜像，再用docker image prune -a删闲置带标签镜像，最后结合--filter条件化清理，并同步处理构建缓存与日志轮转。
清理 Docker 镜像仓库空间，关键不在远程 Registry（如 Docker Hub 或 Harbor），而在于本地镜像缓存、构建中间层、悬空镜像和未被任何镜像引用的层——它们才是真正占用磁盘的“隐形仓库”。深度清理需兼顾安全性与有效性，避免误删共享基础层。
识别可安全清理的镜像类型
真正能释放空间又不破坏运行环境的镜像分两类：
-
悬空镜像（dangling images）：镜像 ID 存在，但仓库名和标签均为
docker build -t app:latest或docker pull后旧镜像失去标签。 -
未被任何容器引用的镜像：手动拉取后从未运行，或容器已删但镜像仍残留。这类镜像不会自动回收，长期积累会显著膨胀
/var/lib/docker。
分阶段执行精准清理命令
按风险由低到高逐步推进，避免一步到位导致误删：
- 仅清理悬空镜像（最安全）：
docker image prune（加-f跳过确认） - 清理所有未被容器使用的镜像（含带标签但闲置的）：
docker image prune -a - 一键清理容器、网络、悬空镜像、构建缓存：
docker system prune - 全量清理（含未挂载卷）：
docker system prune -a --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=nginx:alpine" --filter "until=72h"
治理常被忽略的两大空间黑洞
构建缓存和容器日志是长期运行系统磁盘耗尽的主因，必须同步处理：
-
构建缓存：用
docker builder prune清理 BuildKit 缓存；加-a清全部；加--keep-storage 2g限制缓存上限，防无限增长 -
容器日志：默认 JSON 日志持续追加，单文件可达 GB 级。在
/etc/docker/daemon.json中配置轮转：{"log-driver": "json-file", "log-opts": {"max-size": "10m", "max-file": "3"}}
修改后重启 Docker 服务生效
