docker system prune -a 不能彻底清理所有未用镜像，因它不处理构建缓存、悬空层及带标签闲置镜像；需分步执行：先停删容器与网络，再分别运行 docker image prune -f（悬空镜像）、docker image prune -a -f（未引用带标镜像）、docker builder prune -f（构建缓存），并可用 --filter 精准限定范围。
直接用 docker system prune -a 并不能“彻底”清理所有未使用的镜像——它只清未被容器引用的镜像，但会漏掉构建缓存、悬空层、带标签却闲置的镜像，甚至可能误删共享层。真正彻底，得按类型分步处理。
先停用并清理运行依赖
确保没有容器正在使用目标镜像，否则部分镜像会被跳过：
- 停止所有运行中容器：
docker stop $(docker ps -q) - 删除所有容器（含已停止）：
docker rm -f $(docker ps -a -q) - 清理网络（避免残留桥接干扰）：
docker network prune -f
分三类精准清除镜像残留
Docker 镜像残留不是单一对象，而是三类独立存在的资源，需分别清理：
-
悬空镜像（dangling）：无仓库名和标签，纯中间层，安全可删：
docker image prune -f -
未被引用的带标签镜像：如
redis:7.0已拉取但从没运行过容器，或容器删了但镜像还在：docker image prune -a -f -
构建缓存（BuildKit）：不显示在
docker images中，但占大量空间，存于/var/lib/docker/buildkit/cache：docker builder prune -f（加-a清全部）
用 --filter 锁定范围，避免全局误删
尤其在多项目或 CI/CD 环境下，全局清理风险高。推荐组合过滤：
- 只删 7 天前的旧镜像：
docker image prune -a -f --filter "until=168h" - 只删某应用前缀的镜像：
docker image prune -a -f --filter "reference=myapp:*" - 同时满足标签 + 时间：
docker image prune -a -f --filter "reference=nginx:alpine" --filter "until=48h"
验证清理效果并堵住源头
执行后用 docker system df -v 查看各层级真实占用；再检查 /var/lib/docker/overlay2 是否明显缩小。长期治理建议：
- 在
/etc/docker/daemon.json中配置构建缓存上限：{"builder": {"gc": {"defaultKeepStorage": "20GB"}} - CI 流水线中每次构建后加
docker builder prune -f，防止中断残留 - 禁用
docker system prune -a --volumes（除非确认卷内无数据库快照等关键数据）
