彻底根治 Docker 镜像缓存残留需“删得准、分得清、控得住”，按悬空镜像、未引用带标签镜像、构建缓存三类分级清理，配合 --filter 精准过滤和 daemon.json 配置限制缓存大小与日志轮转。
彻底根治 Docker 镜像缓存残留，关键不是“删得狠”，而是“删得准、分得清、控得住”。系统级清理工具本身不自动识别业务逻辑，必须配合分层策略和运行状态判断，才能避免误删共享层或破坏正在构建的镜像依赖。
先看清哪些东西真能删
Docker 的缓存残留主要分三类，每类清理逻辑不同：
-
悬空镜像（dangling images）：ID 存在但仓库名和标签都是
<none>，常见于重复docker build -t app:latest或docker pull后旧层失标。这类可安全批量清除。 -
未被引用的带标签镜像：比如
nginx:1.25已拉取但从未运行过容器，或容器已删而镜像仍留。它占空间却不提供服务，是重点清理对象。 -
构建缓存（BuildKit cache）：不是镜像，而是构建过程中生成的中间层快照，存于
/var/lib/docker/buildkit/cache。中断构建（如 Ctrl+C）后极易残留，且不显示在docker images中。
用对命令，按风险分级执行
别一上来就 system prune -a。从低风险起步，逐级释放：
- 只清悬空镜像（最保守）：
docker image prune -f - 清所有未被容器使用的镜像（含带标签）：
docker image prune -a -f - 清构建缓存（专治中断残留）：
docker builder prune -f；加-a可清全部缓存层 - 一键整合清理（含停止容器、网络、悬空镜像、构建缓存）：
docker system prune -f
注意：docker system prune -a --volumes 会删未挂载卷，生产环境禁用——除非你确认卷里没数据库快照、日志归档等业务数据。
用 --filter 精准狙击，避免误伤
多项目共存或 CI/CD 环境下，全局清理太粗暴。用 --filter 锁定范围：
- 删 72 小时前的悬空镜像：
docker image prune -f --filter "until=72h" - 只删某应用前缀的旧镜像：
docker image prune -a -f --filter "reference=myapp:*" - 组合条件（如特定标签 + 时间）：
docker image prune -a -f --filter "reference=redis:7.0" --filter "until=168h"
堵住源头：让缓存不再野蛮生长
清理是补救，治理才是根治。两项配置必须做：
-
限制构建缓存大小：在 daemon.json 中加
"builder": {"gc": {"defaultKeepStorage": "2g"}}，重启 Docker 生效。BuildKit 会自动淘汰最久未用缓存。 -
启用日志轮转：默认 JSON 日志不截断，单个文件可达数 GB。在
/etc/docker/daemon.json加入：{"log-driver": "json-file", "log-opts": {"max-size": "10m", "max-file": "3"}}
改完记得 sudo systemctl restart docker。
不复杂但容易忽略。
