关键在于清理本地未被引用的镜像层、构建缓存、日志文件和残留卷；需分阶段执行：docker image prune（悬空镜像）、docker image prune -a（未被容器引用的带标签镜像）、docker system prune（容器/网络/缓存等），生产环境慎用--volumes；辅以--filter定向筛选和日志轮转配置。
清理 Docker 镜像仓库的后端存储空间，关键不在远程 Registry（如 Harbor 或私有仓库）本身是否“删了镜像”，而在于本地或仓库节点上那些未被引用的镜像层、构建缓存、日志文件和残留卷——它们才是真正长期占用磁盘的“隐形垃圾”。深度清理必须分层识别、按需执行，避免误删共享基础层导致镜像损坏。
识别真正可删的镜像类型
Docker 的分层机制决定了不能简单按名称删除。安全清理对象只有两类：
-
悬空镜像（dangling images）：镜像 ID 存在，但仓库名和标签均为 <none>，常见于重复
docker build -t app:latest或docker pull后旧层失去标签 -
未被任何容器引用的镜像：有明确标签（如
redis:7.2），但当前无运行/已停止容器依赖它；这类镜像不会自动释放，需主动清理
分阶段执行精准清理命令
从保守到激进，逐级释放空间，不跳过确认环节（生产环境尤其重要）：
- 仅清悬空镜像（最安全）：
docker image prune，加-f可跳过提示 - 清所有未被使用的镜像（含带标签但无容器在用的）：
docker image prune -a - 一键清理容器、网络、悬空镜像、构建缓存：
docker system prune - 全量清理（含未挂载卷）：
docker system prune -a --volumes—— 生产环境慎用，务必提前确认卷中无业务数据
用 --filter 实现定向清除
避免“一刀切”误伤，通过过滤条件缩小范围：
- 只删 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；加-a清全部，加--keep-storage 2g可限制缓存上限 -
容器日志：默认 JSON 日志持续追加，单个可达 GB 级。建议在
/etc/docker/daemon.json中配置轮转：
{"log-driver": "json-file", "log-opts": {"max-size": "10m", "max-file": "3"}}
修改后需重启 Docker 服务生效。
