Docker 磁盘空间不足时，先确认连接的 daemon 和存储后端，再分别查看镜像共享层、容器可写层、数据卷及日志。docker system df 是分类排查入口，不能把可回收空间直接视为可安全删除的数据。

适用范围与验证状态

本文面向 Linux 主机上的 Docker Engine，使用只读查询定位占用，不执行删除、清空日志、重启 daemon 或存储迁移。Docker Desktop、rootless、远程 daemon 和不同存储后端的路径可能不同。本文为 AI 辅助的官方资料整理，未在目标主机实测；请先核对本机版本与帮助信息。

一、确认查的是哪台 Docker 主机

docker version
docker context show
docker info

记录服务端版本、存储驱动或 snapshotter、Docker Root Dir。context 是入口信息，还需核对实际 endpoint 与环境变量，不能据此断言数据就在当前电脑上。远程连接时，后面的磁盘与目录检查应针对 daemon 所在主机，而不是仅检查运行 CLI 的机器。

尤其不要把所有部署都当成 overlay2：官方说明，Docker Engine 29.0 及以上的新安装默认使用 containerd image store；从旧版本升级的实例不一定自动切换。该后端也可能有独立于 Docker 数据目录的存储位置。参见 containerd image store 官方说明。

二、先看分类，再看明细

docker system df
docker system df -v

先记录各类别的大小、数量与可回收估算，再用详细输出定位候选对象。镜像的 SHARED SIZE 与 UNIQUE SIZE 用于区分共享与独占部分；多个镜像显示的大小不能不加区分地相加。字段与示例见 docker system df 官方文档。

可回收不等于业务上可以删除。旧镜像可能是回滚版本，停止的容器可能仍含待取出的文件，未挂载的数据卷也可能保存业务数据。先确认对象用途、备份和保留期限，再另行制定清理方案。

三、区分容器可写层与挂载数据

docker ps -a --size

用 -a 纳入停止的容器，避免只观察当前运行实例。size 主要描述容器可写层，不是“这个服务的所有数据”；virtual size 还包含镜像内容，共享层不应重复累计。日志和元数据也不能只靠该数值判断，参见 Docker 对容器大小的解释。

对可疑容器，使用下面的只读查询核对挂载。将 CONTAINER 替换为实际容器名或 ID：

docker inspect --format '{{json .Mounts}}' CONTAINER

重点记录 Type、Source、Destination 和数据用途。bind mount 的业务文件位于宿主机路径，不能期待它完全体现在容器可写层中；volume 则需要继续确认卷归属与备份。不要直接删除 Docker 管理的底层目录，也不要在排查期间切换存储后端。

四、单独核对日志驱动

docker info --format '{{.LoggingDriver}}'
docker inspect --format '{{.HostConfig.LogConfig.Type}}' CONTAINER

第一条查看 daemon 默认值，第二条查看指定容器实际使用的类型；不能假设二者始终一致。官方说明，默认 json-file 如果未配置轮转，输出量大的容器可能持续消耗磁盘；local 驱动则默认提供轮转。更改默认驱动也不会自动改造已有容器。参见 Docker 日志配置文档。

本篇不直接覆盖 daemon.json。确认日志确为主要来源后，再为对应容器评估轮转、采集与保留策略；不要通过手工删除正在使用的日志文件来代替驱动级管理。

五、把发现整理成可执行清单

观察到的现象下一步核对
镜像数量多、共享层多区分版本用途和共享层，确认哪些版本仍用于运行或回滚。
单个容器可写层持续增长检查应用临时文件、缓存与写入位置，确认持久数据是否误写到容器层。
卷或绑定目录占用大核对业务归属、实际路径、备份和应用自己的保留策略。
容器 size 不大，主机仍很满继续排查日志、元数据、其他文件系统与独立的 containerd 存储路径。

完成一轮排查后，用同一 context、同一主机、相近业务时段重新采样，比较增长来源。不要承诺某条命令能释放固定比例的磁盘，也不要为了让统计数字下降而删除尚未确认的数据。

结果与边界

这一流程的输出应是一份“对象、大小、增长趋势、业务用途、后续负责人”的清单，而不是直接运行全局清理命令。查询输出可能包含内部路径和容器名称，分享排查材料前应脱敏。

相关阅读