Docker Desktop 把 C 盘占满怎么办？WSL2 VHDX 清理、压缩与迁移完整教程
Docker Desktop 把 C 盘占满怎么办？WSL2 VHDX 清理、压缩与迁移完整教程
**先给结论：**不要直接删除
ext4.vhdx或docker_data.vhdx，也不要一上来执行wsl --unregister。正确顺序是：先用docker system df -v找到镜像、停止容器、卷和 Build Cache 的真实占用；备份数据库与重要卷；按对象清理；如果 Docker 内部空间已经下降但 Windows 中 VHDX 文件仍很大，再完全退出 Docker Desktop、执行wsl --shutdown，备份后压缩动态 VHDX；如果 C 盘长期空间紧张，优先使用 Docker Desktop 的 Settings → Resources → Advanced 修改磁盘镜像位置，而不是照搬旧版“注销 docker-desktop-data”的教程。
Windows 开发机用久以后，经常出现一种很反直觉的现象：docker image prune 已经删除很多镜像，Docker Desktop 也显示释放了几十 GB，但资源管理器里的 C 盘几乎没有变化；继续追查，会在 %LOCALAPPDATA%\Docker\wsl 附近发现一个巨大的 VHDX 文件。
问题不是 Docker “删不干净”，而是很多教程混淆了三个不同空间：Docker 对象的逻辑占用、WSL2 内部 ext4 文件系统的已用块，以及 Windows 宿主上动态扩展 VHDX 的物理文件大小。只有先分清这三层，才能知道应该清理、压缩还是迁移。
本文面向 Windows 10/11 + Docker Desktop + WSL2 后端。不同 Docker Desktop 版本的数据布局会变化：有的旧版本能看到 docker-desktop-data 发行版和 ext4.vhdx，较新安装可能主要使用 docker_data.vhdx，所以不要把网上某个固定文件名或固定目录当成事实。先在自己的机器上确认，再操作。
一、为什么删完镜像，C 盘还是没有变小？
图 1：prune 只处理 Docker 逻辑对象，使 ext4 中部分块变为空闲；动态扩展 VHDX 不一定自动缩小，宿主空间可能要到 compact 阶段才归还。卷默认保留，只有显式确认后才处理。原创教学图（Image2 生成）。
第一层是 Docker 逻辑对象：
- 镜像层与悬空镜像；
- 正在运行或已经停止的容器；
- 容器可写层与日志；
- 命名卷、匿名卷和数据库文件；
- BuildKit/Buildx 构建缓存；
- 不再使用的网络。
第二层是 WSL2 内部的 Linux 文件系统。Docker 删除镜像层后，ext4 把相应块标记为空闲，它们可以被以后写入复用。此时 docker system df 会下降，Linux 视角的可用空间也会增加。
第三层是 Windows 看见的动态 VHDX 文件。动态磁盘会随写入增长，但删除内部文件并不等于物理文件立刻收缩。微软 compact vdisk 文档也明确说明：动态扩展 VHD 会随添加文件而增大，却不会因为删除文件自动减小；compact 的作用才是减小物理文件。
所以必须记住：
Docker prune：释放 VHDX 内部可复用空间
VHDX compact：尝试把空闲块归还给 Windows/NTFS
迁移磁盘位置：从根本上改变以后增长发生在哪个盘
三者解决的问题不同。只想让后续镜像能继续写入，清理 Docker 对象可能已经够了；希望资源管理器中的 C 盘立即增加可用空间，往往还需要压缩；系统盘容量长期不足，则应该迁移磁盘位置。
二、第一步永远是盘点，不要先运行带 --volumes 的清理命令
先运行：
docker system df
docker system df -v
docker container ls -a --size
docker volume ls
docker buildx du
docker system df 给出 Images、Containers、Local Volumes、Build Cache 的汇总，-v 显示明细。RECLAIMABLE 表示 Docker 判断当前可回收的空间，但它不等于 Windows C 盘最终一定增加同样大小：共享镜像层可能被多个镜像引用，VHDX 也可能没有立即物理收缩。
图 2：Docker 官方说明 docker system df 用于查看 Docker daemon 的磁盘占用，-v/--verbose 输出详细信息。来源：Docker Docs，原始页面。
建议先把输出保存下来，清理后再比较。素材包里的 code/docker-disk-audit.ps1 只做只读盘点，不删除任何数据：
powershell -ExecutionPolicy Bypass -File .\code\docker-disk-audit.ps1
它会记录 Docker 占用、命名卷和 WSL 发行版列表。真正排查时，还应查看 Docker Desktop 的 Images、Containers、Volumes 与 Builds 页面，确认体积最大的对象属于哪个项目。
哪些对象最容易悄悄变大？
Build Cache 经常是第一名。多阶段构建、频繁变化的 COPY . .、不同平台 Buildx 构建会留下大量缓存。它们不一定出现在普通镜像列表中，因此只看 docker images 会漏掉。
数据库卷 可能比镜像更大。MySQL binlog、PostgreSQL WAL、Elasticsearch 索引、MinIO 对象数据都可能藏在 volume 中。它们通常是业务数据，不是“缓存”。
容器日志 也可能失控。默认 json-file 日志没有合理轮转时，一个高频服务可以产生数十 GB 日志。删除容器能移除其可写层和日志，却可能同时让未持久化数据消失。
旧架构镜像 容易在 Buildx 环境中堆积。开发者切换 amd64/arm64 或建立多个 builder 后，缓存分散在不同构建器里。
三、安全清理顺序：低风险对象先处理，卷最后单独审核
图 3：先盘点、再按对象清理、单独审核卷，最后才压缩或迁移。禁止直接删除 VHDX，unregister 前必须有可验证备份。原创教学图（Image2 生成）。
1. 先清理 Build Cache
docker builder prune
docker buildx prune
命令会先列出将回收的内容并要求确认。若需要按时间过滤，可以使用对应命令支持的 until 过滤条件；不要为了图省事一律加 -a -f。活跃项目可能仍依赖缓存加速，清空后下一次构建会重新下载和编译，网络与构建时间都会增加。
2. 清理悬空或明确不用的镜像
docker image ls
docker image prune
docker image prune -a
不带 -a 主要处理悬空镜像；带 -a 会删除未被任何容器引用的镜像。它不会判断“你下周是否还要用”，因此清理前要看仓库、标签、创建时间和项目文档。私有镜像如果无法重新拉取，先 docker save 备份。
3. 审核并删除停止容器
docker container ls -a --size
docker container prune
停止容器可能仍保存调试现场或没有挂载卷的数据。先检查 docker inspect <container> 的 Mounts，确认重要数据是否在命名卷或 bind mount 中。容器可写层不是可靠备份。
4. 最后才考虑 docker system prune
Docker 官方说明，默认 docker system prune 会删除停止容器、未使用网络、悬空镜像和未使用构建缓存；默认不会删除卷，这是为了避免重要数据意外丢失。
docker system prune
docker system prune -a
-a 扩大到所有没有被容器引用的镜像。不要把下面这条当成日常清理命令：
# 高风险示例：只有完成卷审计和备份后才考虑
docker system prune -a --volumes
官方当前文档中，--volumes 会处理未使用的匿名卷；不同对象和 Compose 命令对命名卷、匿名卷的删除语义不同。不要只凭“unused”判断数据库卷无价值。项目停止后，卷可能暂时没有容器引用，却仍是唯一数据副本。
5. Compose 项目不要随手加 -v
docker compose down
docker compose down -v
默认 down 删除容器和网络；-v/--volumes 还会删除 Compose 声明的命名卷和附加的匿名卷。对于 MySQL、PostgreSQL、Redis 持久化或本地对象存储，这可能等价于删库。先核对 Compose 文件中的 volumes:，再决定。
四、备份不是复制容器名：必须验证数据能恢复
压缩和迁移前至少做两类备份。
第一类是业务级备份。数据库使用其原生一致性工具，例如 mysqldump、pg_dump，或停止写入后复制经过验证的数据目录。对命名卷，可以启动一次性容器把内容打包到宿主目录：
docker run --rm `
-v my_database_volume:/source:ro `
-v ${PWD}:/backup `
alpine sh -c "cd /source && tar czf /backup/my_database_volume.tar.gz ."
第二类是 Docker Desktop 磁盘级备份。Docker 官方备份文档指出，Docker Desktop 无法启动、需要重装时，可以备份其 VM 磁盘；Windows 当前文档示例使用 %LOCALAPPDATA%\Docker\wsl\data\docker_data.vhdx。但路径与文件名随版本、安装方式和设置变化，必须以本机实际位置为准。
只复制 VHDX 之前要退出 Docker Desktop 并 wsl --shutdown，避免复制到正在写入的不一致状态。复制完成后记录文件大小和哈希，并在有条件时做一次恢复演练。没有验证过的备份只是一份希望。
五、如何找到真正的 VHDX，而不是套用旧教程路径？
先确认 WSL 和后端状态：
wsl --version
wsl --list --verbose
docker info --format '{{json .DriverStatus}}'
Docker 官方当前 WSL 文档说明，默认 WSL2 引擎数据位于：
C:\Users\[USERNAME]\AppData\Local\Docker\wsl
但内部结构可能是 data\docker_data.vhdx、disk\docker_data.vhdx，也可能是旧布局下的 ext4.vhdx。如果你已经在 Docker Desktop 中改过位置，文件自然不在默认目录。使用资源管理器或 PowerShell只读搜索目标目录：
Get-ChildItem "$env:LOCALAPPDATA\Docker\wsl" `
-Filter *.vhdx -Recurse -ErrorAction SilentlyContinue |
Select-Object FullName, Length, LastWriteTime
不要在整个系统盘上直接批量修改或删除搜索结果。电脑中可能还有 Ubuntu、Debian、Android 模拟器、Hyper-V 虚拟机使用的其他 VHDX。
六、清理后 C 盘仍没变化：压缩 VHDX 的两种方式
压缩前的共同条件：
- 重要卷、镜像或整个 VHDX 已备份；
- 所有容器已停止；
- 从托盘菜单彻底退出 Docker Desktop，而不是只关闭窗口；
- 管理员 PowerShell 执行
wsl --shutdown； - 再次检查
wsl --list --running，确认没有发行版占用磁盘； - 目标文件没有开启 NTFS 压缩或加密。
图 4：两种路径都要求先退出 Docker 与 WSL、备份并确认磁盘未占用。DiskPart 使用只读挂载后 compact；Optimize-VHD 需要 Hyper-V PowerShell 模块。原创教学图（Image2 生成）。
方式 A：DiskPart，Windows 内置
以管理员身份打开 PowerShell，运行 diskpart，然后逐行输入：
select vdisk file="D:\实际路径\docker_data.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk
exit
微软文档说明，compact vdisk 只能处理动态扩展 VHD，目标必须被选中，并且应处于分离状态或以只读方式挂载。压缩可能产生大量 CPU 与磁盘 I/O，文件越大耗时越久，不要在笔记本即将断电时执行。
方式 B：Optimize-VHD，需要 Hyper-V PowerShell 模块
Optimize-VHD -Path "D:\实际路径\docker_data.vhdx" -Mode Full
如果提示“无法将 Optimize-VHD 识别为 cmdlet”，说明当前系统没有可用的 Hyper-V PowerShell 模块，而不是 VHDX 一定损坏。Windows 家庭版或未启用相关组件的环境更适合使用 DiskPart。不要为了执行一条命令随意安装不明脚本。
为什么压缩后效果可能不明显？
VHDX 只有在内部存在可识别、可回收的空闲块时才能明显缩小。如果真正占用来自仍保留的数据库卷、日志或 Build Cache，先 compact 不会创造空闲空间。文件系统中的空闲块分布、零块、稀疏属性和当前 WSL/Docker 版本也会影响结果。
因此先比较三组数字：清理前后 docker system df -v、VHDX 文件大小、Windows C 盘可用空间。不要根据某篇文章声称“必定从 100GB 变 20GB”来判断成功与否。
七、长期方案：优先从 Docker Desktop 设置迁移磁盘位置
图 5：Docker 官方文档说明 WSL2 数据默认在 %LOCALAPPDATA%\Docker\wsl，并建议从 Settings → Resources → Advanced 修改位置。来源：Docker Docs，原始页面。
当前 Docker Desktop 版本支持时，优先使用界面：
Docker Desktop
→ Settings
→ Resources
→ Advanced
→ Disk image location
选择空间充足、稳定的本地 NTFS 分区，例如 D:\DockerData。迁移前备份并停止开发任务；迁移期间不要强制结束 Docker Desktop；完成后检查新位置的 VHDX、C 盘旧文件是否按预期处理，并运行：
docker version
docker container ls -a
docker image ls
docker volume ls
docker system df
再启动一个测试容器，验证镜像拉取、容器创建、卷读写和端口映射。如果 Docker 提示目标位置已有磁盘镜像，必须确认它究竟是旧数据还是空目录，不要盲目选择覆盖。
为什么不把“导出 → unregister docker-desktop-data → import”作为首选？因为这是针对特定旧版布局的做法。较新版本的 Docker Desktop 存储实现和发行版列表可能已经不同，内部发行版属于 Docker 管理；错误执行 wsl --unregister 会永久删除对应发行版数据。官方设置界面能让当前版本按自身规则迁移，风险更可控。
如果设置中没有 Disk image location，先确认自己使用的是 WSL2 还是 Hyper-V/Windows containers 后端，并更新 Docker Desktop 与 WSL。企业设备还可能被管理员策略锁定设置，此时应与管理员确认，而不是绕过策略修改内部文件。
八、迁移以后，如何避免 D 盘再次变成“新 C 盘”？
1. 为容器日志设置轮转
Docker Engine 配置可为 json-file 设置 max-size 和 max-file。修改默认值只影响新建容器，旧容器需要重建或单独配置：
{
"log-driver": "json-file",
"log-opts": {
"max-size": "20m",
"max-file": "3"
}
}
具体容量应依据故障排查与合规要求确定，不要为了省空间把日志窗口缩到无法排错。
2. 优化 Dockerfile 缓存边界
把依赖清单与业务源码分开 COPY，完善 .dockerignore，避免每次改一行源码就让所有依赖层失效。多阶段构建只把运行需要的产物复制进最终镜像。Docker 官方构建缓存文档指出，ADD/COPY 会基于文件元数据计算缓存校验，构建上下文过大也会增加缓存压力。
3. 为 BuildKit 设置垃圾回收
Docker BuildKit 有周期垃圾回收机制。对频繁构建多架构镜像、空间受限的开发机，可以根据工作负载调整保留策略；但默认 GC 对多数用户已经足够，不应未经测量就激进清空所有缓存。
4. 数据库数据使用明确命名卷或宿主备份
不要把唯一数据留在匿名卷或容器可写层。Compose 中为数据库声明可识别的命名卷，配置定期逻辑备份，并记录恢复步骤。这样清理时能分辨哪些卷是临时缓存，哪些是业务资产。
5. 每月盘点，不要等系统盘变红
可以定期运行只读审计脚本，记录 docker system df -v、VHDX 大小和磁盘剩余空间。当 Build Cache、日志或卷增长速度异常时提前处理。
九、常见报错与排查
在进入报错处理前，建议先做一次“三次快照”实验。它能把“命令没效果”变成可以定位的数据。
快照 A：清理前
记录以下内容：
docker system df -v | Out-File .\before-docker-df.txt -Encoding utf8
Get-PSDrive C | Format-List | Out-File .\before-c-drive.txt -Encoding utf8
Get-Item "D:\实际路径\docker_data.vhdx" |
Select-Object FullName, Length, LastWriteTime |
Out-File .\before-vhdx.txt -Encoding utf8
快照 B：只清理 Docker 对象后
再次执行相同命令。如果 Docker 的 reclaimable 和内部占用显著下降，而 VHDX 文件大小与 C 盘可用空间几乎不变，说明逻辑清理已经成功，问题位于物理收缩阶段。不要反复运行更激进的 prune；它不会解决 VHDX 没收缩，反而增加误删风险。
快照 C：压缩或迁移后
压缩完成后比较 VHDX 文件大小与 C 盘剩余空间；迁移完成后确认新位置文件持续更新，旧位置没有另一份仍被 Docker 使用的磁盘。最后重新运行 docker system df -v，确保逻辑对象数量没有异常归零。
三次快照至少能区分四种情况：清理命令没有删到真正大户；逻辑空间释放但物理文件未缩；压缩完成但文件中仍有真实数据；迁移后旧副本没有被正确清理。每一种情况的下一步完全不同。
九点五、几个特别容易造成误判的空间数字
镜像 SIZE 不能简单相加
多个镜像会共享基础层。docker image ls 中每个镜像显示的 SIZE 包含可共享层，如果把所有行直接相加，往往高估实际占用。docker system df -v 的 SHARED SIZE 与 UNIQUE SIZE 更有参考价值。
RECLAIMABLE 不是承诺释放给 C 盘的字节数
它描述 Docker 对象层可以回收多少，不包含 VHDX 收缩效率、文件系统碎片、稀疏块和宿主保留空间。清理 30GB 对象，不保证 Windows 立刻增加 30GB。
df -h 与 VHDX 文件大小观察的是不同层
Linux 中 df -h 表示文件系统容量和已用块；Windows 文件属性表示虚拟磁盘后端文件占用了多少 NTFS 空间。前者下降、后者不变并不矛盾，正是动态扩展磁盘的典型表现。
Volume 显示 0B 不代表里面一定没数据
某些 Docker 统计不能准确遍历或归属所有卷内容，数据库也可能通过 bind mount 写到宿主其他目录。应结合 docker volume inspect、容器 Mounts 和实际目录检查，不能只看一列 SIZE。
十、日志、卷和 Build Cache 的深度定位
如果 docker system df 看不出原因，应继续向对象内部查，而不是直接压缩整个磁盘。
定位容器日志
docker inspect --format '{{.LogPath}}' <container-name>
docker inspect --format '{{json .HostConfig.LogConfig}}' <container-name>
不要在 Windows 资源管理器中直接删除正在使用的 Linux 日志文件。先修正日志驱动和轮转配置，再重建容器。手动清空文件可能导致 daemon 与文件句柄状态不一致，也会掩盖为什么日志失控。
定位卷属于哪个容器
docker volume inspect <volume-name>
docker container ls -a --filter volume=<volume-name>
对 Compose 项目，还要查看自动生成的 <project>_<volume> 名称。项目目录改名后，旧卷可能成为“孤儿”，但里面仍保存旧数据库。先挂载为只读，检查关键表或文件，再决定归档或删除。
定位 Buildx 缓存
docker buildx ls
docker buildx du
docker buildx prune
多个 builder 可能各自持有缓存。确认当前 builder、驱动和用途；CI 测试残留的 builder 可以在确认无用后移除，日常开发 builder 则应保留必要缓存。
十一、为什么“移动 VHDX 文件再做目录链接”不作为首选？
网上还有一种方法：退出 Docker 后把 VHDX 手动移动到 D 盘，再用目录联接或符号链接欺骗原路径。它看似通用，却绕过 Docker Desktop 对磁盘路径、权限、升级和故障恢复的管理。
这种做法可能遇到目标盘暂时离线、权限继承变化、安全软件拦截、升级程序不识别链接、NTFS 压缩属性继承、Docker 启动时创建新空磁盘等问题。更危险的是，用户看到 C 盘和 D 盘各有一个 VHDX，却不知道当前 daemon 正在写哪一个。
只要当前版本提供 Disk image location，就应使用官方设置。企业批量安装可以评估 Docker 安装器当前支持的 --wsl-default-data-root，但它面向安装部署，不等于可以随意改造既有环境。任何手工迁移都必须有版本对应文档、完整备份与回滚步骤。
十二、恢复验证：迁移完成不等于任务完成
迁移或压缩后按从基础到业务的顺序验证：
wsl --status和wsl --list --verbose正常；- Docker Desktop 启动且
docker version同时返回 Client/Server； docker image ls与清理后预期一致；docker container ls -a中保留的容器仍存在；docker volume ls与备份清单一致；- 启动一个无状态测试容器，验证网络和文件写入；
- 启动数据库项目，执行只读查询核对关键数据；
- 重启 Windows，再重复验证一次；
- 检查新 VHDX 的 LastWriteTime 是否随新镜像拉取变化；
- 保留旧备份一段观察期，确认稳定后再按计划销毁。
验证中若发现数据缺失，立即停止创建新镜像和容器，避免新写入覆盖可恢复空间。先保存诊断信息，再从业务备份或冷备 VHDX 恢复。不要在同一个损坏文件上连续尝试多个来源不明的“修复命令”。
报错 1：The process cannot access the file because it is being used
说明 VHDX 仍被 Docker Desktop、WSL 或相关进程占用。完全退出托盘图标，执行：
wsl --shutdown
wsl --list --running
不要用任务管理器随意结束虚拟磁盘写入进程，也不要在文件仍被占用时强制复制或压缩。
报错 2：Virtual disk files must be uncompressed and unencrypted
微软 WSL 故障文档指出，VHDX 所在目录启用 NTFS 压缩或加密可能导致虚拟磁盘限制错误。检查目录属性 → 高级，取消“压缩内容以便节省磁盘空间”和不适用的加密。不要把 NTFS 文件压缩与 VHDX compact 混为一谈。
报错 3：Optimize-VHD 不是命令
这是模块不可用。使用管理员 PowerShell 确认：
Get-Command Optimize-VHD -ErrorAction SilentlyContinue
Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All
若系统版本不支持，使用 DiskPart 路径即可。
报错 4：清理后 Docker Desktop 启动失败
先不要删除更多文件。记录报错，检查 wsl --status、wsl --list --verbose 和 Docker Desktop Troubleshoot 日志。如果你修改了磁盘位置，确认目标分区在线、路径权限正常、VHDX 没被压缩/加密。必要时用已经验证的 VHDX 备份恢复。
报错 5：卷显示 unused，能不能删？
“没有容器引用”只描述当前关系，不描述业务价值。先运行：
docker volume inspect <volume-name>
结合 Compose 文件、项目文档和卷内数据判断。数据库项目暂时 down 后，命名卷很可能显示未使用，但下一次 up 正需要它恢复数据。
十三、方案决策：清理、压缩、迁移还是重建？
图 6：短期回收先清理；内部已释放但宿主空间不变时压缩；长期治理优先使用 Docker Desktop Settings 迁移；只有环境损坏且能够重建时才考虑重建。原创教学图（Image2 生成）。
可以按下面的判断执行：
docker system df -v显示大量可回收对象：先清理；- Docker 占用下降、VHDX 文件仍很大：备份后压缩；
- C 盘本来就小，开发镜像会持续增长：从 Settings 迁移到数据盘；
- Docker 环境已经损坏，但镜像可重新拉取、数据库有独立备份：最后才重建；
- 重要数据只有一个卷副本：先停止一切破坏性操作，完成业务级备份。
十四、发布前可直接照着执行的检查表
- 已记录
docker system df -v清理前输出； - 已确认最大占用来自镜像、缓存、容器、日志还是卷；
- 数据库做了原生逻辑备份；
- 重要命名卷已经打包并验证文件可读取；
- 没有把
--volumes当成默认参数； - 没有直接删除 VHDX；
- 没有对未知发行版执行
wsl --unregister； - 压缩前已退出 Docker Desktop 并执行
wsl --shutdown； - VHDX 路径来自本机检查，而不是复制别人的旧路径；
- 迁移优先使用当前 Docker Desktop 的 Settings；
- 完成后验证容器、镜像、卷、端口和数据库数据；
- 已配置日志轮转和周期盘点，避免再次爆盘。
总结
Docker Desktop 占满 C 盘不是一个“删哪个文件”的问题，而是一个分层存储问题。docker system prune 只负责 Docker 对象层；ext4 释放的块仍位于 WSL2 虚拟磁盘内部；VHDX compact 才可能把这些块归还给 Windows；Disk image location 则决定未来数据继续在哪里增长。
最稳妥的顺序是：**先盘点，后清理；先备份，后压缩；短期回收用 compact，长期治理用官方设置迁移。**任何宣称“直接删 VHDX”“直接 unregister 就能释放几十 GB”的教程，只要没有说明版本、备份与恢复验证，就不适合作为生产开发机的第一选择。
更多推荐
10
0- 0
已为社区贡献5条内容
所有评论(0)