Docker 的磁盘占用问题在 Windows 环境中尤为突出，因为 Docker Desktop 依赖 WSL2 虚拟磁盘来存储镜像层、容器写入层和数据卷。随着开发过程不断拉取镜像、启动容器、安装依赖，C 盘空间可能迅速减少。要搞清楚空间被谁消耗，最直接的命令就是 docker system df。它从镜像、容器、本地卷、构建缓存四个维度统计占用量，并计算可回收空间。下面分析这条命令的具体用法和输出细节。
一、docker system df 的基础用法与输出字段
不带任何参数执行 docker system df 时，Docker 会返回一个汇总表格。表格默认包含五行，分别对应 Images（镜像）、Containers（容器）、Local Volumes（本地数据卷）和 Build Cache（构建缓存），最后一行是总计。每一行又分为 TYPE、TOTAL、ACTIVE、SIZE、RECLAIMABLE 五个字段。TOTAL 表示该类型对象的总数量，ACTIVE 表示正在被运行的容器或容器所引用的对象数量，SIZE 表示该类型对象占用的磁盘空间总和，RECLAIMABLE 表示可以被安全回收的空间大小以及占该类型总大小的百分比。
这些数值并不是文件系统级别的精确测量，而是 Docker 基于对象引用关系和层共享情况估算出来的结果。例如镜像的总大小通常会大于实际磁盘占用，因为多个镜像可能共享相同的基础层，Docker 在计算每个镜像大小时会把共享层的体积重复计入，但在磁盘上只有一份真实数据。因此 RECLAIMABLE 列显示的“可回收空间”是一个上限值，实际清理后释放的空间通常会略有出入。
以下是一个典型的输出示例，可以看出各类对象的数量和可回收空间占比：
docker system df TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 12 8 3.45GB 1.20GB (35%) Containers 5 3 250MB 80MB (32%) Local Volumes 10 4 1.8GB 600MB (33%) Build Cache 20 0 2.1GB 2.1GB (100%)
从输出中可以发现，构建缓存的可回收比例经常达到 100%，这是因为构建过程中产生的中间层通常不会被任何容器或镜像直接引用。如果 Docker 主机持续运行构建任务而不清理缓存，这部分空间会快速增长，往往是 Windows 上 C 盘空间不足的主要元凶之一。
二、使用 -v 参数查看逐项明细
docker system df -v 是 docker system df 的详细模式，它会列出每一个镜像、容器、数据卷以及构建缓存的具体名称、ID、大小和引用状态。这个模式非常适合在空间告急时快速定位具体是哪一个镜像或数据卷占用了最多空间。例如某个镜像的 SIZE 可能达到 1.2GB，但它的 ACTIVE 状态为 false，说明它没有被任何容器使用，这就属于可以直接删除的对象。
详细输出中会额外显示 SHARED SIZE 和 UNIQUE SIZE 两列数据。SHARED SIZE 表示该镜像与其它镜像共享的层大小，UNIQUE SIZE 是该镜像独有的层大小。当多个镜像都基于同一个 ubuntu:22.04 或 node:20 基础镜像时，基础层的体积会被多个镜像共享。因此你不能简单地将所有镜像的 SIZE 加总来推断磁盘占用，而应该更关注 UNIQUE SIZE 和 RECLAIMABLE 的总量。理解这一点可以避免误判某台机器的 Docker 空间使用量过高。
这条详细命令在 Windows 上同样适用，但它只反映 Docker 内部的数据视图。要想知道 Docker 在 Windows 物理磁盘上真正占用了多少空间，还需要结合 Windows 的目录检查。典型的存储位置位于 C:\Users\你的用户名\AppData\Local\Docker\wsl\data\ext4.vhdx，该文件是 WSL2 虚拟磁盘的主体，可能因为 Docker 内部的镜像层和可写层累积而膨胀到几十 GB。虽然它可能包含已经不再使用的数据，但 Docker 并不会自动缩小这个虚拟磁盘文件，必须通过内部的 prune 系列命令清理后再考虑压缩磁盘。
执行 docker system df -v 的命令如下：
docker system df -v
输出会非常长，通常配合 grep 或 findstr 来过滤关键字。在 Windows PowerShell 中可以这样操作：
docker system df -v | Select-String -Pattern "Images|REPOSITORY|TAG"
这条命令能帮你快速定位镜像空间占用的重点，而不必在几十行输出中逐行查找。
三、Windows 路径定位与清理策略
在 Windows 上使用 Docker Desktop 时，所有镜像、容器读写层和数据卷都存储在 WSL2 虚拟磁盘文件中。默认文件路径为 C:\Users\你的用户名\AppData\Local\Docker\wsl\data\ext4.vhdx。除此之外，还可能存在 C:\Users\你的用户名\AppData\Local\Docker\wsl\data\ext4.vhdx 的同目录下其他虚拟磁盘文件，例如 ext4.vhdx 的备份或者 data.vhdx。这些文件都属于 Docker 的存储范围，任何一个文件过大都会直接挤占 C 盘空间。需要注意的是，即使 Docker 内部的 docker system df 显示总占用只有 3GB，虚拟磁盘文件本身可能已经达到 10GB，因为其中还包含文件系统元数据、日志以及已删除但尚未被复用或压缩的空间。
要释放空间，首先要根据 docker system df 的结果判断主要占用来源，然后使用对应的清理命令。如果镜像是主要占用源，执行 docker image prune -a 可以删除所有没有被任何容器引用的镜像。如果构建缓存过大，执行 docker builder prune 可以清理所有构建缓存。如果数据卷过多，执行 docker volume prune 会删除所有没有被容器使用的匿名卷和具名卷。容器本身的可写层占用一般较小，但如果有大量停止的容器，可以用 docker container prune 清理。这些命令都可以单独执行，也可以使用 docker system prune -a --volumes 一次性清理所有未使用的镜像、容器、网络和数据卷，但该命令会删除未被使用的一切对象，执行前务必确认没有需要保留的自定义镜像或数据卷。
以下是一个安全的清理流程，先查看再删除：
# 查看详细占用 docker system df -v # 删除所有停止的容器 docker container prune # 删除所有未被引用的镜像（包括有标签的） docker image prune -a # 删除所有构建缓存 docker builder prune # 删除未被使用的本地卷 docker volume prune
清理完成后，可以再次执行 docker system df 查看空间回收情况。如果虚拟磁盘文件仍然很大，可以在 Docker Desktop 设置中重启 WSL 集成，或者通过 WSL 的 Optimize-VHD 命令压缩虚拟磁盘，但这属于较高级的操作，建议在完全了解风险后再进行。Windows 用户尤其要注意，删除数据卷是不可逆的，如果某个卷中包含数据库初始化数据或应用状态，请先用 docker run -v 卷名:/backup alpine tar cvf /backup/backup.tar /data 之类的方式做好备份。
四、常见误区与磁盘管理最佳实践
很多人在分析 Docker 磁盘占用时只看 TOTAL 列，认为镜像数量多、总大小大就是问题核心，于是频繁删除镜像。实际上真正消耗磁盘空间的往往是无引用镜像和构建缓存，它们的 RECLAIMABLE 占比非常高。另一个常见误区是误以为删除容器就能释放大量空间，事实上容器的可写层单独占用通常只有几十 MB，真正的大头来自镜像层和数据卷。如果容器停止后不删除，它会继续引用其底层镜像，导致那些镜像无法被 docker image prune 回收。
还有一个容易被忽视的问题是构建缓存。开发者每天多次执行 docker build，每次构建都会产生新的层缓存，即使最终的镜像只有一百多 MB，缓存积累数月后也可能达到数 GB。在 Dockerfile 中频繁使用 RUN apt-get update 或者 COPY . . 这类会破坏缓存一致性的指令，会加速缓存膨胀。最佳实践是在项目根目录配置 .dockerignore 文件，排除 node_modules、.git、日志文件等无关内容，减少构建上下文体积；同时使用多阶段构建，只将最终产物复制到运行时镜像，降低最终镜像的大小。
对于 Windows 用户，建议定期执行 docker system df 并把输出保存到日志中，观察一个月内各项指标的变化趋势。如果发现构建缓存总是快速回归，可以考虑在 CI/CD 流水线中增加清理步骤，例如每次构建成功后自动运行 docker builder prune --filter until=24h 只清理超过一天的缓存，既不会影响短期构建效率，又能控制空间增长。最后，不要轻易重置 Docker Desktop 或删除 WSL 虚拟磁盘文件，那会丢失所有镜像和数据卷，只有在 docker system df -v 明确显示无重要数据且常规清理无效时才考虑这种极端操作。
docker system df磁盘使用分析Docker空间清理修改时间：2026-08-30 08:35:38