抹茶柚子冰如果你在 WSL2 里跑 Ubuntu 22.04，大概率遇到过或者即将遇到这个场景：在 bash 里敲下 rm -rf 删掉几十 GB 的日志、Docker 镜像和缓存，回到 Windows 资源管理器一看，C 盘可用空间不仅没涨，反而又少了点。第一次遇到这事，我还以为是回收站或者系统还原在搞鬼，查了一圈才发现，问题出在 WSL2 的虚拟磁盘文件 ext4.vhdx 上——它只会在需要时变大，删除文件后并不会自动收缩。这篇文章我就把完整的压缩思路和实操步骤写下来，从 vhdx 的原理到 diskpart 压缩，再到 Docker Desktop 干扰、稀疏虚拟磁盘这些坑，一次讲透。适合刚接触 WSL2 的新手，也适合在 C 盘告急边缘挣扎的老用户。
1. 先搞清楚空间去哪了：vhdx 只涨不缩的文件系统真相
1.1 动态扩展磁盘：只负责长大，不负责瘦身
WSL2 不是传统意义上的 Linux 虚拟机，它实际跑在一个轻量级 Hyper-V 虚拟机里。Ubuntu 22.04 的整个文件系统被封装在一个虚拟磁盘文件 ext4.vhdx 中，默认放在 Windows 用户目录下。WSL2 创建这个文件时采用“动态扩展”模式，什么意思呢？就是一开始它可能只有几 GB，随着你往里面装软件、拉 Docker 镜像、编译代码，文件会慢慢向外扩张，直到到达 256GB 的上限。
问题恰恰出在“动态扩展”只有扩张机制，没有自动收缩机制。你在 Ubuntu 里删除文件时，Linux 的 ext4 文件系统只是把这些数据块标记为“空闲”，并不会主动把底层虚拟磁盘里的区域清空，也不会告诉 Hyper-V“这里可以释放了”。于是 ext4.vhdx 这个文件在 Windows 眼里始终保持着历史最高水位。哪怕你删了 100GB 数据，它的体积依然纹丝不动，甚至因为删除操作产生的新元数据，还会不降反升。
打个比方：vhdx 就像带隔间的仓库，货物运走之后隔间骨架还在，仓库占地不会因为少了几件货就自动变小。只有管理员走进来把空隔间拆掉，仓库才会恢复原状。在 WSL2 里，这个“拆隔间”的动作就叫压缩虚拟磁盘。
1.2 三个“大小”对不上是正常的：used、du、vhdx
判断要不要压缩、能压缩回多少，首先得区分三个概念：
| 指标 | 来源 | 描述 |
|---|---|---|
df -h / 的 Used |
WSL 内部 | 文件系统认为当前实际占用的空间 |
du -sh |
WSL 内部 | 某个路径下真实文件的总大小 |
ext4.vhdx 文件大小 |
Windows 资源管理器 | 宿主机视角下虚拟磁盘文件体积 |
这三者本来就对不上。我手头这台 Windows 11 + Ubuntu 22.04，长期用 Docker 构建镜像，df 显示 Used 只有 48GB，但 ext4.vhdx 已经长到 163GB。中间差的 115GB 全是历史幽灵数据，不压缩的话，Windows 会一直把这 115GB 当成已占用空间，C 盘可用空间自然越来越少。
所以压缩前的核心判断逻辑就是一句话：vhdx 文件大小减去df 里的实际 Used，差值越大，压缩收益越高。如果差值只有两三 GB，就别折腾了。
1.3 删除文件只是第一步，fstrim 才是关键
很多人压缩失败或者压缩后空间没变化，原因就是漏了一个动作：fstrim。
删除文件本身只是把块标记为“空闲”，Hyper-V 底层并不知道哪些块可以回收。fstrim 的作用是扫描文件系统里的空闲块，并向虚拟磁盘发送 TRIM/UNMAP 指令，告诉底层“这些区域已经没用了，可以释放”。做了这一步，后面的压缩才有空间可收。
bash复制sudo fstrim -av
这命令会把所有已挂载文件系统都执行一遍 TRIM。在 WSL2 里，这步做得越彻底，后面压缩效果越好。如果跳过，直接去 diskpart compact，运气好能回收一点，运气不好可能一点变化都没有。
注意：fstrim 不是 Windows 的回收站清空，它只负责给底层“报空”，真正的空间回收还得靠下一步的虚拟磁盘压缩操作。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 压缩前的容量清理与可回收空间估算
2.1 先找出吃空间的大户，别上来就压缩
如果你直接压缩一个装满垃圾数据的 vhdx，效果会非常有限。压缩的本质是把空洞释放出来，而空洞源于被删除的文件。你都没删东西，自然没洞可收。所以正确顺序是：先清理真实垃圾，再 fstrim，最后压缩。
在 Ubuntu 22.04 里，按我的经验，空间大户基本按这个顺序排列：
- Docker：
/var/lib/docker下的镜像、容器、数据卷、构建缓存。这往往是 vhdx 膨胀最疯狂的源头，尤其是频繁构建镜像时，overlay2 层会堆出大量重复数据。 - 软件包缓存：
/var/cache/apt/archives里的.deb包。 - Python/pip 缓存：
~/.cache/pip。 - conda 缓存：
conda clean --all。 - systemd 日志：
/var/log/journal，journalctl 默认可以无限增长。 - 内核模块和编译中间文件：如果你编译过内核或者其他 C/C++ 项目，
/usr/src和build目录经常被忽略。
快速定位大目录可以这样：
bash复制sudo du -x -h --max-depth=1 / 2>/dev/null | sort -hr | head -20
2.2 针对性的清理命令
Docker 清理是最暴利的一步，我建议先执行：
bash复制docker system df
docker system prune -a -f
prune -a 会把所有未被容器使用的镜像和构建缓存一并删掉，包括 dangling 镜像。有人担心会不会误删，其实只要容器在运行，它依赖的镜像不会动；停掉的容器依赖也会被清理掉，如果你确定不需要这些容器，这个命令很安全。
apt 缓存和日志：
bash复制sudo apt clean
sudo journalctl --vacuum-size=200M
sudo journalctl --vacuum-time=7d
Python、npm、conda：
bash复制pip cache purge
npm cache clean --force
conda clean --all
清理完这些，再看一眼 df -h /，通常能看到立竿见影的变化。我遇到过一台开发机，光 docker system prune 就回收了 80 多 GB 的逻辑空间，当然，磁盘文件还是不变，得靠后面的压缩操作。
2.3 清理后执行 fstrim，顺手统计可回收空间
清理完成，回到 Linux 侧执行 TRIM：
bash复制sudo fstrim -av
如果输出显示某个挂载点 trimmed 了多少字节，说明空闲块已经被通知到底层。这一步可能要等几分钟，取决于文件系统大小和空闲块数量。
接着到 Windows PowerShell 里查 vhdx 大小：
powershell复制Get-ChildItem "$env:LOCALAPPDATA\Packages\*\LocalState\ext4.vhdx" | Select-Object FullName, @{n='SizeGB';e={[math]::Round($_.Length/1GB,2)}}
拿到 vhdx 实际大小后，和前面 df -h 的 Used 对比。差值就是理论可回收量。举个例子，vhdx 是 90GB，df 显示用了 40GB，那最多能压回 50GB 左右，但通常不会压到完全持平，因为文件系统元数据、日志和块分配策略还会保留一点余量，最终能压到 45~50GB 就算很理想了。
如果这个差值小于 5GB，我劝你别在这上面耗时间，收益太低。先把重心放在 2.1 的清理上，或者直接考虑第 5 章的搬盘方案。
3. 核心实操：wsl --shutdown 配合 diskpart 一次压回几十 GB
3.1 备份这一步不要省
压缩虚拟磁盘本质上是对 vhdx 文件做元数据重写，出问题的概率不高，可一旦出错，轻则 WSL 无法启动，重则整个 Ubuntu 文件系统损坏。我见过有人在压缩时强制关机，结果 vhdx 直接打不开，只能从头重装。
备份有两个选择：
powershell复制# 方式一：导出整个发行版到 tar
wsl --export Ubuntu-22.04 D:\backup\ubuntu2204_$(Get-Date -Format yyyyMMdd).tar
# 方式二：直接复制 vhdx 文件（前提是 WSL 已关闭）
Copy-Item "C:\Users\dev\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu22.04LTS_79rhkp1fndgsc\LocalState\ext4.vhdx" D:\backup\
方式一的 tar 文件通常比 vhdx 小很多，因为只包含实际文件数据；缺点是导出时间较长。方式二更快，但 vhdx 文件很大时，需要足够的磁盘空间存放备份。
3.2 完整压缩流程：一条命令都不许少
压缩的核心套路是：在 WSL 内做 fstrim -> wsl --shutdown 让虚拟机彻底停机 -> 用 diskpart 把 vhdx 挂载为只读 -> compact -> 分离。
第一步：WSL 内部最后确认一次 TRIM
bash复制sudo fstrim -av
exit
第二步：在管理员 PowerShell 里彻底关闭 WSL
powershell复制wsl --shutdown
这一步最关键。只点掉 Ubuntu 窗口右上角的叉，或者运行 exit，都不能保证虚拟机真正停机。WSL2 的后台服务可能还会因为 Windows Terminal 的残留进程、VSCode 的 WSL 插件、Docker Desktop 而自动唤醒。执行完务必验证：
powershell复制wsl -l -v
看到所有发行版的 STATE 都是 Stopped，才能继续。
第三步：确认 vhdx 精确路径
powershell复制(Get-ChildItem "$env:LOCALAPPDATA\Packages\*\LocalState\ext4.vhdx").FullName
我的路径一般是：
C:\Users\dev\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu22.04LTS_79rhkp1fndgsc\LocalState\ext4.vhdx
第四步：用 diskpart 压缩
创建一个文本文件 compress.txt，内容如下：
code复制select vdisk file="C:\Users\dev\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu22.04LTS_79rhkp1fndgsc\LocalState\ext4.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk
然后在管理员 PowerShell 里执行：
powershell复制diskpart /s compress.txt
看到类似“DiskPart 已成功压缩虚拟磁盘文件”的输出，就成功了。这里有个反直觉的点：虽然用了 attach vdisk readonly，但 diskpart 仍然能执行压缩，这是微软官方文档明确支持的操作方式，放心用。
第五步：验证结果
powershell复制wsl -d Ubuntu-22.04
df -h /
确认文件系统正常后，在 Windows 里重新查看 vhdx 大小：
powershell复制Get-ChildItem "$env:LOCALAPPDATA\Packages\*\LocalState\ext4.vhdx" | Select-Object FullName, @{n='SizeGB';e={[math]::Round($_.Length/1GB,2)}}
正常情况下，文件体积会明显缩小，大概率能接近 df 的 Used 值。
3.3 为什么我推荐 diskpart，而不是其他工具
有人会说可以用 Optimize-VHD，这是 Hyper-V 自带的压缩 cmdlet：
powershell复制Optimize-VHD -Path C:\path\to\ext4.vhdx -Mode Full
但这个命令只有 Windows 专业版/企业版并启用了 Hyper-V 模块的机器能用。很多人装 WSL2 时根本没启用 Hyper-V 管理器，PowerShell 里会直接报“无法识别 Optimize-VHD”。diskpart 是 Windows 自带的底层磁盘工具，兼容性最好，一条批处理到处能用，不需要额外安装任何东西。
另外一个方案是 wsl --export + wsl --import，这相当于把文件系统复制到一个全新 vhdx 里，天然紧凑，不需要 attach/compact。但缺点是耗时长、导入后默认用户变 root、还要处理默认用户配置。本地压缩，diskpart 是最省事的选择。
4. 压缩翻车现场：那些让 vhdx 纹丝不动的元凶
4.1 “虚拟磁盘正在使用”或“附加失败”的排查思路
这是我遇到最多的报错。执行 diskpart 时，如果提示虚拟磁盘正被另一个进程使用，十有八九是 wsl --shutdown 没有真正让虚拟机停机。优先级最高的排查对象是 Docker Desktop。
Docker Desktop 的 WSL2 后端会常驻一个 vmmemWSL 进程，即使 Docker Desktop 界面关了，它也可能在后台运行。处理办法：
powershell复制Stop-Service com.docker.service -Force
wsl --shutdown
然后再执行 wsl -l -v 确认状态。
如果还有进程残留，可以看看任务管理器里是否有 vmwp 或 vmmem，有就结束它们。注意，结束 vmmem 可能会导致其他 WSL 发行版的工作丢失，最好在确认没有关键任务后再操作。
4.2 compact 执行很久没反应，是卡住还是正常的？
如果你之前没做 fstrim，或者 vhdx 已经膨胀到 200GB，compact 扫描整个虚拟磁盘会非常慢，几十分钟都有可能。它看起来像卡住，实际在后台挨个块检查。我的建议是：
- 压缩前一定跑 fstrim，空洞多了 compact 反而快。
- 准备一个空闲时间窗口，别在赶着用电脑的时候压缩。
- 如果超过一小时还没任何输出，再考虑是否中止，但要有心理准备，中止后 vhdx 可能处于不一致状态，需要重新执行。
4.3 压缩后 vhdx 还是那么大？问题多半出在“又被偷偷拉起来了”
压缩成功不等于空间一定回收。我踩过的一个坑是：VSCode 的 WSL 插件在压缩过程中自动重连，把 WSL 重新拉起来，导致 diskpart 之后的 vhdx 又被重新分配。
判断方法简单：压缩完成后立刻再执行一次：
powershell复制wsl -l -v
如果发现某个发行版的 STATE 是 Running，说明压缩过程中有程序把它唤醒了。常见的元凶包括：
- VSCode 的 Remote-WSL 插件。
- Windows Terminal 的“启动时自动恢复”会话。
- 任务计划程序里配置的 WSL 启动项。
- Docker Desktop 开机自启。
最好的做法是压缩前把这类应用全部退出，甚至断开网络，避免后台自动重连。
4.4 权限不够导致 attach 失败
diskpart 必须以管理员身份运行。如果你在普通 PowerShell 里执行，attach 时大概率会收到“拒绝访问”的报错。这看起来像 bug，其实只是 UAC 权限问题。右键 PowerShell 图标，选择“以管理员身份运行”，再执行一遍。
另一个容易忽略的点：如果之前用 wsl --import 把发行版搬到 D 盘，vhdx 路径就不是默认的 AppData\Local\Packages 了。这时候需要根据实际路径操作，别拿着默认路径硬套。
4.5 迁移/导入后默认用户变成 root 的处理
如果你最终选择 wsl --export + wsl --import，导入后默认用户会变成 root，这是个老坑。解决办法有两种：
bash复制# 方法一：编辑 /etc/wsl.conf，添加
[user]
default=你的用户名
powershell复制# 方法二：用发行版可执行文件指定
ubuntu2204.exe config --default-user 你的用户名
方法二对微软商店版更友好，方法一更通用。迁移后顺便确认一下文件权限，特别是 home 目录，因为 root 导入可能导致部分文件 owner 错乱。
5. 长期维护方案：搬盘、稀疏虚拟磁盘与一键压缩脚本
5.1 从根本解决 C 盘压力：把发行版搬到非系统盘
压缩只是治标，如果 C 盘本身空间紧张，每次扩容压力都很大，最直接的办法是把整个 WSL 发行版迁移到 D 盘或其他数据盘。
迁移命令：
powershell复制wsl --export Ubuntu-22.04 D:\wsl-backup\ubuntu2204.tar
wsl --unregister Ubuntu-22.04
wsl --import Ubuntu-22.04 D:\WSL\Ubuntu22.04 D:\wsl-backup\ubuntu2204.tar --version 2
执行 unregister 前，务必确认 tar 文件导出完整且能正常访问。我第一次迁移时没注意 tar 文件损坏，结果原发行版被删了，新发行版又导不进去，只能重新配环境，教训深刻。迁移后记得处理默认用户问题（见 4.5）。
5.2 新版 WSL 的稀疏虚拟磁盘：真正的一劳永逸
如果你的 WSL 版本比较新，可以试试一个很少有人提到的特性：稀疏虚拟磁盘。
powershell复制wsl --manage Ubuntu-22.04 --set-sparse true
执行后，vhdx 会变成稀疏文件。稀疏文件的特性是：未占用的块不会真正占用磁盘物理空间，Windows 会把它们当作空洞处理。也就是说，以后你在 Ubuntu 里删除文件，只要执行过 fstrim，Windows 的可用空间会直接变大，不需要再手动跑 diskpart。
我自己的使用体验是：设置稀疏后，日常开发几乎感受不到差异，但是磁盘占用长期保持在一个很健康的状态。前提是你的 WSL 版本支持这个命令，执行 wsl --version 能正常输出版本号基本就可以试。如果报错，就继续用 diskpart 方案。
注意：稀疏 vhdx 对云同步工具不太友好。如果
AppData\Local\Packages被 OneDrive、坚果云之类的工具扫描，稀疏文件可能引起不必要的同步上传。遇到这种情况，把 vhdx 目录加入同步排除列表即可。
5.3 一键压缩脚本：每个月跑一次，告别空间焦虑
清理 + 压缩这套流程完全可以脚本化。下面这个 PowerShell 脚本我一直在用：
powershell复制# 以管理员身份运行
# 1. 在 WSL 内部执行 fstrim 和日志清理，用 root 避免 sudo 密码
wsl -d Ubuntu-22.04 -u root -e bash -c "fstrim -av; journalctl --vacuum-size=200M"
# 2. 关闭 WSL
wsl --shutdown
# 3. 找 vhdx 并压缩
$vhdx = (Get-ChildItem "$env:LOCALAPPDATA\Packages\*\LocalState\ext4.vhdx" -ErrorAction SilentlyContinue).FullName
if (-not $vhdx) {
Write-Host "未找到 vhdx 文件"
exit 1
}
$scriptContent = @"
select vdisk file="$vhdx"
attach vdisk readonly
compact vdisk
detach vdisk
"@
$scriptContent | Out-File "$env:TEMP\wsl_compact.txt" -Encoding ascii
diskpart /s "$env:TEMP\wsl_compact.txt"
把脚本存成 .ps1，用任务计划程序设置为每月执行一次，基本能避免“空间突然满”的尴尬。
几个细节：
- 用
wsl -u root而不是wsl -e bash -c "sudo..."，可以避免 sudo 密码卡住自动化脚本。 - 清理日志我放在了压缩前，配合 fstrim 一起做，效果更好。
- 如果 vhdx 路径有空格，diskpart 脚本里的双引号必须保留，否则会识别失败。
5.4 Docker Desktop 的磁盘限制与自动回收
如果你主要用 WSL2 跑 Docker，Docker Desktop 的虚拟磁盘镜像会随着镜像构建和容器运行不断膨胀。在 Docker Desktop 的 Settings -> Resources -> Advanced 里，可以手动设置 Disk image size 上限，比如 32GB 或 64GB。这个上限不是“当前大小”，而是允许 Docker 虚拟磁盘增长的最大值，设置合理后能避免它无限制占满 C 盘。
新版本 Docker Desktop 也提供了镜像清理功能，在 Troubleshoot 页面里有相关内容。本质上，它做的事情还是“清理镜像层 + 压缩虚拟磁盘”，跟本文的思路完全一致。日常开发中多看一眼 docker system df，及时 prune，比等磁盘满了再抢救省事太多。
最后再分享一个我自己的经验：有次我在 WSL 里跑数据分析脚本，生成了几十 GB 的中间文件，删完后顺手执行了 fstrim，结果压缩时忘了关 Docker Desktop，diskpart 连续报了三次“正在使用中”。从那以后我养成一个习惯，压缩前先看任务管理器里有没有 vmwp 进程，有就先退出 Docker Desktop，再执行 wsl --shutdown。这套流程跑下来，每次都能稳定把 100GB+ 的 vhdx 压回 40GB 以内。如果你的 WSL2 也遇到了“越删越满”的怪象，不妨按这个顺序试一遍。