docker system prune 是最安全的“一键清理”入口，仅删除已停止容器、悬挂镜像和未被引用的构建缓存，不触运行中资源，执行前交互确认，加 -f 可跳过，但不清理 volume（需显式加 --volumes）。

docker system prune 是最安全的“一键清理”入口

想快速释放磁盘空间，又怕误删正在用的东西？docker system prune 就是为此设计的默认守门员——它只动真正闲置的资源，不碰运行中或有依赖的容器、镜像、网络和构建缓存。

• 默认行为：删除所有已停止的容器、所有悬挂镜像（dangling=true）、所有未被容器引用的构建缓存
• 不会删除：正在运行的容器、有标签且被某容器引用的镜像、用户显式创建的网络或卷
• 执行前会交互确认，加 -f 可跳过（例如：docker system prune -f）
• 注意：它不清理 volume（除非加 --volumes），因为卷常含业务数据，Docker 默认不敢动

docker image prune -a 能清掉“没被任何容器用”的所有镜像

你执行过 docker images 后发现一堆带 <none></none> 标签的镜像，或者反复 build 生成了大量旧版本镜像？docker image prune -a 就是专治这类“无主镜像”的命令。

• docker image prune 默认只删悬挂镜像（dangling）；加 -a 才扩展到所有未被当前任何容器（无论运行/停止）引用的镜像
• 常见误判点：某个镜像虽没容器在用，但它是另一个镜像的父层（比如 ubuntu:22.04 是你自定义镜像的基础），此时它仍会被保留——Docker 的分层机制会自动保护共享层
• 如果想连“一小时前建的镜像”都不要，可加过滤：docker image prune -a -f --filter "until=1h"

强制删镜像前，先查谁在用它：避免 “conflict: unable to delete”

执行 docker rmi 报错 Error response from daemon: conflict: unable to delete ...: conflict: unable to delete ... (must be forced)？这不是权限问题，而是镜像正被某个容器（哪怕是已退出的）引用着。

• 先查谁在依赖它：docker ps -a --filter "ancestor=<image-id-or-name>" --format "{{.ID}} {{.Status}} {{.Names}}"</image-id-or-name>
• 若返回结果，说明有容器基于该镜像创建过——哪怕已 Exited，rmi 仍会拒绝（防止误删导致无法 start）
• 稳妥做法：先 docker rm 掉那些已退出的容器（docker rm $(docker ps -q -f status=exited)），再试 rmi
• 真要绕过检查？加 -f：但后果是——如果还有运行中容器用它，docker start 会失败，别怪命令没提醒你

彻底清空？小心 /var/lib/docker 里的“硬核残留”

跑完 system prune 还剩几十个 GB？可能是构建缓存、匿名卷、或被 docker load 进来的离线镜像没走标准流程，躲过了 prune 检测。

• docker system df 是你的第一双眼睛：它会分块显示 Images、Containers、Local Volumes、Build Cache 各占多少，精准定位胖头在哪
• 构建缓存特别能吃空间：docker builder prune（或 docker buildx prune，取决于你用的 builder）可单独清它
• 卷（volume）不随容器删而删，docker volume ls + docker volume rm 才能动手；但务必确认里面没数据库文件、日志或上传内容
• 极端情况（如重装 Docker 前）才建议手动删 /var/lib/docker：这会干掉所有镜像、容器、卷、网络，且不可逆——systemctl stop docker 必须先做，否则文件系统可能损坏

真正难的不是命令记不住，而是分不清“这个镜像到底还有没有容器在逻辑上依赖它”。Docker 的分层和引用计数藏得深，docker system df -v 和 docker image inspect 多看两眼，比盲目 rmi -f 省三天排障时间。