WSL2磁盘空间不足？从20GB无损扩容到200GB实操手册

先说说我这台机器的来龙去脉。我用的是 Windows 10 下的 WSL2，发行版选的 Ubuntu 18.04，本来是图省事，想在 Windows 里写写 ROS 代码、编点 C++ 小程序，图一个启动快、不折腾双系统。结果用着用着，某天终端里突然飘红：No space left on device。一开始我以为是 /tmp 满了，清理一下就算了。后来又过了一段时间，连 apt update 都跑不完，系统提示磁盘空间不足，我才意识到，问题出在 WSL2 的虚拟磁盘本身——默认 20GB 的上限，被我塞满了。

如果你想在 Windows 下长期用 WSL2 跑 Ubuntu 18.04，尤其是做机器人、SLAM、深度学习这类依赖重型库的开发，那这篇内容就是写给你看的。我会把 WSL2 磁盘扩容的原理、我踩过的坑、以及一套能从 20GB 直接扩到 200GB 的完整操作流程，全部摊开讲清楚。这不是什么高深莫测的黑科技，但照着网上零散的教程做，十有八九会在某一环节卡住，甚至搞坏整个子系统。我会尽量把“为什么这么做”也讲明白，知其然也知其所以然，遇到异常时你才有能力自己判断。

1. 先搞懂 WSL2 的虚拟磁盘是怎么“长大”的

1.1 ext4.vhdx 到底是什么

WSL2 和早期的 WSL1 完全不同。WSL1 是一个系统调用翻译层，文件操作直接映射到 Windows 的 NTFS 文件系统上；WSL2 则是一个真正运行在轻量级虚拟机里的 Linux 内核。既然是虚拟机，那 Linux 的根文件系统就不能直接铺在 Windows 的 C 盘上，而是以一块虚拟磁盘的形式存在。这块虚拟磁盘在 Windows 里的表现形式，就是一个文件，路径类似：

code复制C:\Users\<你的用户名>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc\LocalState\ext4.vhdx

注意这里的 ext4.vhdx，它不是像普通单文件那样密密麻麻占满空间。它采用的是 VHDX（Virtual Hard Disk v2）动态扩展格式。什么意思呢？就是这块虚拟磁盘有一个“上限值”，比如默认的 20GB，但实际它占用的物理空间只等于你真正写入的数据量。如果你只用了 5GB，那 ext4.vhdx 文件在 C 盘上大约也就 5GB+ 左右；当你把数据一路写到 20GB，这个文件就会慢慢膨胀到接近 20GB，并且一旦达到设定上限，就再也不能写入新数据了。

这就造成了一个很尴尬的现状：你在 WSL2 的 Ubuntu 18.04 里执行 df -h，看到根分区是 /dev/sdb 或 /dev/sda，容量固定 20GB，不会因为你把 WSL2 放在 D 盘就变成 100GB。WSL2 发行版的“系统盘”容量是在创建时由发行版安装包决定的（一般是 20GB 或 1TB，取决于 Windows 和 WSL 的版本；多数情况下是 20GB 初始上限）。

1.2 为什么 Ubuntu 18.04 特别容易爆盘

如果你只是拿 Ubuntu 18.04 来敲几个 Linux 命令、跑点简单脚本，20GB 绰绰有余。但一旦进入稍微重型一点的场景，空间就不够看了。

• ROS（机器人操作系统）：如果你装的是 ros-melodic-desktop-full，那基本上一套下来就是 4~6GB，加上编译过程中产生的 .o、.a 中间文件、依赖的库文件，直接翻倍。
• 编译工具链：build-essential、cmake、gcc、g++，这些虽然单个不大，但关联依赖一堆。
• CUDA 和 cuDNN：哪怕只是装个 CUDA 11.x 的 runtime 和 toolkit，也是 3~4GB 起步。
• Python 虚拟环境和 pip 缓存：~/.cache/pip 很容易积攒几个 GB 的 wheel 包。
• Docker 镜像和数据卷：很多人在 WSL2 里启用 Docker Desktop 的 WSL2 backend，镜像默认也存在这个发行版的虚拟磁盘里，几个镜像下来 10GB 就没了。

还有一个容易被忽略的：ROS 编译工作空间。我自己建了一个 catkin_ws，里面 src 代码可能不到 1GB，但 build 和 devel 目录如果你不清理，动辄 10GB 以上。尤其是 devel 目录里每一项编译产物都可能膨胀好几倍。Ubuntu 18.04 配套的是比较老的库，遇到最新代码时往往需要从源码编译，那些源码包、opencv 的 contrib 模块、PCL、Eigen，随便一个从源码编译，中间文件占个 5GB 都不奇怪。

当你发现 df -h 显示 /dev/sdb1 已经 100% 时，在 Linux 里面基本上是无解的——很多操作（比如 apt install、apt upgrade、创建临时文件）都需要写盘，但你连写一个 1KB 的文件都做不到。这时候你是没法直接在 Ubuntu 内部“删一删就完事”的，因为关键的系统缓存和 /var 目录可能早就塞满了。

1.3 磁盘满后的一系列连锁反应

在我实际经历中，WSL2 磁盘满的时候，并非所有的空间都被真实数据占用。这里面有一个 WSL2 非常典型的“坑中之坑”——Linux 删除文件后，空间并不一定立即释放回 Windows。

原因在于 VHDX 文件的释放机制。你在 Ubuntu 里 rm 掉一个大文件，ext4 文件系统层的“块”被标记为可用，但是对于承载 VHDX 的 Windows 文件系统来说，VHDX 文件自己并不清楚这些块是否已经空出来。除非你通过特殊的手段“压缩”VHDX，否则它在 Windows 上显示的物理大小，只会涨，不会自动减。

所以有时候你会遇到这样的情况：在 Ubuntu 里杀掉了很多缓存文件，df -h 也显示可用空间多了，但是 C 盘或者 D 盘的剩余空间并没有回来。这就是为什么很多人扩容 WSL2 之后，发现 C 盘还是红的——你只清理了内部虚拟磁盘，没有处理 VHDX 文件本身的物理大小。

在动手扩容之前，最好先做个心理建设：如果你的 C 盘（或 WSL2 发行版所在盘）剩余空间已经低于 10GB，那你需要先想办法腾点空间出来，因为扩容操作本身，可能需要在承载 VHDX 的那个磁盘分区上临时写入几个 GB 的数据（比如我后面要讲的导出、导入，或者用 diskpart 操作时产生的文件变化）。

2. 两种绕不开的扩容思路：在线扩容和离线扩容

2.1 “在线扩容”的局限性，以及它是不是伪需求

很多教程会教你一种听起来很“优雅”的方法：用 wsl --resize 命令，或者在 WSL 配置文件中设置 [automount] 和 [wsl2] 里的 swap、memory，完全没提磁盘大小调整。早期 WSL2 版本确实没有提供类似 wsl --resize-disk <Distro> <Size> 的命令，后续虽然有一些支持的动向，但在稳定的 Windows 10/11 版本上，不少人的 WSL 还停留在 v1 或 v2 的某些老版本。实际上对 Ubuntu 18.04 来说，最稳妥的在线扩容路径是：

code复制wsl --shutdown

然后找到 ext4.vhdx，用 diskpart 对虚拟磁盘进行扩展。但这里有个关键点：WSL2 的根文件系统分区表默认是 GPT，并且最后一个分区（即根分区）往往已经占满了整个虚拟磁盘。 在线扩展虚拟磁盘大小之后，你还需要在 Linux 内部操作分区表和文件系统，而在 WSL2 的默认情况下，系统启动时并不会自动执行分区调整——所以你需要进入一个手动流程：growpart 或 fdisk 删除再重建分区、resize2fs 扩展文件系统。

所以，我认为对新手来说，“在线扩容”这两个字很容易产生误导。你以为运行一条命令就完事了，实际上里面还牵涉虚拟磁盘 VHDX 扩展、分区表调整、文件系统扩增这三轮操作，每一步都有可能出问题。而且，VHDX 文件正被 WSL2 虚拟机进程占用时，Windows 侧的工具往往无法直接修改它，你无论如何都要先做 wsl --shutdown。从实践的角度看，这和“离线扩容”没有本质区别。

2.2 “重建发行版”这种粗暴路子，为什么我不推荐

最粗暴的扩容思路是：把你现有的 Ubuntu 18.04 环境里要的资料打包备份，然后卸载这个发行版，重新装一个默认上限更大的版本，或者用 wsl --export 导出再 wsl --import 导入。

我不能说这个路子不行，它确实能解决容量问题——导出为一个 tar 或 vhdx，导入的时候可以指定新虚拟磁盘大小？这里就涉及 WSL 版本的差异了。在老版本的 WSL2 上，wsl --import 到一个新目录，默认会生成一块上限为 20GB 的 ext4.vhdx，你还是得想办法扩容。而且在较新的版本上，wsl --install 创建发行版时，系统会通过注册表项里的 VhdSize 来决定初始大小，默认常被设置为 1TB（所以你有时会看到新装的 Ubuntu 用 df -h 查看就有 1TB，其实是动态上限，不是实际占用）。

但我不推荐导出/导入的理由很简单：

• 麻烦：你需要停掉所有 WSL 实例，执行 wsl --export，等待几十 GB 的打包，再重新导入，再设置默认用户，还要修复 Windows Terminal 的配置、环境变量，以及各种 WSL 里配置的网络代理等。
• 容易出错：导出出来的压缩包很大，时间久，中途一旦磁盘空间不够或杀毒软件拦截，直接失败。
• 环境一致性：如果你在 Ubuntu 18.04 里安装过一些自己编译的库，且没有记录安装过程，导出导入后这些库大概率还能用，但涉及到一些绑定到特定路径、特定内核模块的软件（例如某些使用 /dev 直接操作的驱动、自定义 systemd 服务），很可能在导入后出现问题。

与其大动干戈地重装环境，不如直接对虚拟磁盘文件本身做一次“体外手术”。这也是我这篇文章的核心思路：你想扩展的是一块“硬盘”的容量，那我们就直接解决“硬盘”的容量问题，而不是把整个系统备份一遍再重灌。

3. 实操开始：通过 diskpart 直接扩展 VHDX 容量

3.1 第一步：定位 ext4.vhdx 文件，并做好备份

首先，你需要确认真实发行版名称以及对应 vhdx 文件的存放位置。以 Ubuntu 18.04 为例，最常见的路径是：

code复制C:\Users\<用户名>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc\LocalState\ext4.vhdx

注意 79rhkp1fndgsc 这个字符串是发行版 publisher ID，可能因安装来源不同略有差异，如果你是通过 Microsoft Store 安装的，通常就是这段。还有一种情况，如果你是自己使用 LxRunOffline 或 wsl --import 把发行版迁移到 D 盘的，那么路径就需要你去对应目录里找 ext4.vhdx。

一个比较通用的查找命令是在 PowerShell 里执行：

powershell复制Get-ChildItem -Path "$env:LOCALAPPDATA\Packages" -Filter "ext4.vhdx" -Recurse -ErrorAction SilentlyContinue | Select-Object FullName, @{Name="SizeGB";Expression={[math]::Round($_.Length/1GB,2)}}

找出来后，先不要急着操作。请务必先做好备份。你可能会想：备份一个 20GB 的 vhdx 文件，哪有那么多空间？其实对于大多数情况，你可以只备份关键数据，没必要备份整个虚拟磁盘。但考虑到接下来要对磁盘文件本身做结构变更，如果操作不当，有损坏整个系统映像的潜在风险，我建议你至少复制一份 ext4.vhdx 到外部存储，或者把 WSL 里重要的代码、工作空间用 tar 打包到 Windows 文件系统下：

bash复制tar -czvf /mnt/d/backup_home_$(date +%Y%m%d).tar.gz /home

别嫌这一步多余。我身边就有人因为在扩容前没备份，结果在用分区工具操作的时候不小心选了“转换 MBR/GPT”或“删除卷”，整个 WSL2 镜像直接打不开，之前编译了半年的代码和调好的环境付之东流。如果你是资深玩家，可以靠日常 git 提交找回大部分代码，但对于那些没纳入版本控制的配置文件、数据集、模型权重，就没有后悔药了。

3.2 第二步：彻底关闭 WSL2 子系统

接下来要确保 WSL2 处于完全停止状态。不是说你关掉 WSL 窗口就行，因为后台可能还有 WSL 进程在运行（比如 Docker Desktop 的 backend、Windows Terminal 的自动后台进程等）。

在 Windows PowerShell（管理员权限）里执行：

powershell复制wsl --shutdown

执行完以后，用下面的命令确认状态：

powershell复制wsl --list --verbose

正常来说，所有发行版应该都显示为 Stopped。如果输出为空或仅显示操作系统信息，那也正常。

这里有个很多人忽视的细节：如果你启用了 Windows 的“虚拟机监控程序”平台，或者安装了 Docker Desktop，那么 wsl --shutdown 后 Docker Desktop 的 backend WSL 发行版（比如 docker-desktop）也可能占用着 ext4.vhdx 文件。建议再顺手把 Docker Desktop 退出：

powershell复制Get-Process "Docker Desktop" -ErrorAction SilentlyContinue | Stop-Process -Force

同时最好去服务管理器里看看，有没有 LxssManager 或 WSLService 还在跑，如果有，先尝试用 net stop 停掉。总之，修改 ext4.vhdx 文件的前提是这个文件没有被任何进程锁定。这一步没做干净，后面 diskpart 会报“虚拟磁盘正在使用中”之类的错误，或者虽然在 diskpart 里能 attach，但操作到一半报 IO 错。

3.3 第三步：用 diskpart 将 VHDX 文件挂载为虚拟磁盘

打开一个管理员权限的命令提示符，输入 diskpart 进入磁盘交互工具。然后依次执行：

bat复制select vdisk file="C:\Users\<用户名>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc\LocalState\ext4.vhdx"
attach vdisk readonly

这里比较关键的是 readonly 参数。只读挂载的目的是让 Windows 能够读取 VHDX 内部的分区结构，但不允许 Windows 侧未经允许修改。如果你不加 readonly 直接 attach，Windows 可能会认为这是一块新磁盘并尝试给它分配盘符，如果某个文件系统它以 NTFS/exFAT/FAT32 的身份去识别失败，还会弹出“需要格式化”的提示，一旦点错，数据就没了。所以永远要加 readonly，安全第一。

挂载成功之后，你可以通过下面命令查看磁盘列表：

bat复制list disk

你会看到虚拟磁盘已经出现在列表里，但因为没有分配盘符，所以不会在“此电脑”里显示。然后查看分区信息：

bat复制select disk 1
detail disk

这个 disk 1 的编号可能因机器而异，以你实际看到的为准。detail disk 会展示当前磁盘的大小、分区布局。正常情况下你会看到两块分区：一个很小的 EFI 系统分区（ESP），一个大的根文件系统分区。这个根文件系统分区就是 Ubuntu 根分区，它的体积目前等同于 VHDX 最大容量（20GB）。

如果你熟悉 Linux 的 fdisk 工具，会发现这里的分区布局和 Linux 看到的一样。这个 VHDX 本质上是一个 GPT 格式的虚拟磁盘，里面有两个分区：分区1是 EFI，分区2是根分区。我们接下来要做的，是把这个“虚拟磁盘”的上限从 20GB 扩展到目标大小，然后再从根分区里“挪用”新的未分配空间，并入根分区。

3.4 第四步：扩展 VHDX 虚拟磁盘大小上限

在 diskpart 里，对 VHDX 动态磁盘扩展上限的命令是：

bat复制select vdisk file="C:\Users\<用户名>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc\LocalState\ext4.vhdx"
expand vdisk maximum=200000

这里 maximum=200000 的单位是 MB，也就是把虚拟磁盘上限扩大到约 200GB。注意，expand vdisk 调整的是 VHDX 的“最大可写容量”，并不是立刻让 C 盘少 200GB。由于 VHDX 是动态扩展格式，执行完这条命令后，ext4.vhdx 文件本身的物理大小并不会马上变大，它只是在 VHDX 头文件里把容量上限改成 200GB。

所以要理解：磁盘上限 200GB ≠ 实际占用 200GB。你仍然像以前一样正常使用，直到内部数据超过 20GB，文件才会慢慢继续变大。这是一个动态的过程。因此，不必担心“扩到 200GB 会不会把 C 盘塞满”，这个担心没有意义；真正的限制反而是你的 Windows 系统盘剩余空间，因为虚拟磁盘文件是存放在那里的，它的物理体积永远不能超过 Windows 分区剩余容量。

如果你想把系统迁移到 D 盘再扩容，那就得先做 wsl --export 和 wsl --import 到 D 盘，再把新位置的 ext4.vhdx 拿来做同样的操作。这里我不展开迁移细节，重点先讲扩容。

执行完 expand 之后，可以用命令验证：

bat复制select vdisk file="..."
detail vdisk

在输出信息中会显示“最大大小”已经变成 200GB。此时先不要退出 diskpart，我们接下来要把它分离（detach），因为如果继续以只读方式挂载，Windows 没有理由去修改分区表。

bat复制select vdisk file="..."
detach vdisk

分离成功后，再用 exit 退出 diskpart。

3.5 第五步：启动 WSL2 进入 Linux，调整分区和文件系统

这时候虚拟磁盘的最大容量已经变为 200GB，但是 Ubuntu 18.04 里的根分区仍然只有 20GB 可用（因为分区表里根分区的“大小”属性还写着 20GB）。重新启动 WSL2：

powershell复制wsl --distribution Ubuntu-18.04

进入系统后，先看下当前磁盘和分区结构：

bash复制sudo fdisk -l /dev/sda

输出会显示：

• /dev/sda1：EFI 分区（很小，通常 512MB）
• /dev/sda2：Linux filesystem（根分区，目前容量还是 20GB）
• 磁盘总大小已经变成 200GB，所以 sda2 后面有大约 180GB 的未分配空间。

此时需要把剩余空间合并到根分区。有两个工具推荐：growpart（它专门用来扩展分区大小）和 resize2fs（它用来扩展文件系统）。Ubuntu 18.04 默认不一定预装 cloud-guest-utils（提供 growpart 命令），如果执行 growpart 提示命令不存在，需要安装：

code复制sudo apt update
sudo apt install cloud-guest-utils

如果 apt update 因为磁盘满报错，你可以先临时清理一下空间，比如删除 /var/cache/apt/archives/*.deb、清理 pip 缓存、清理 journal 日志等。后面第六节我会专门讲如何清理出一部分操作缓冲空间。

如果你实在没法安装 cloud-guest-utils，也可以直接用 fdisk（交互模式）删除 /dev/sda2 分区再从相同起始扇区重建一个占满剩余空间的新分区，但这是一项更危险的操作，一旦起始扇区写错，整个分区表会被破坏。我们这里使用更安全的 growpart 自动计算分区边界：

bash复制sudo growpart /dev/sda 2

注意这里是 /dev/sda 和分区号 2 之间有一个空格，不是 /dev/sda2。执行成功后输出通常会显示 CHANGED 以及新旧分区大小。

分区变大之后，文件系统还认为自己的大小没变。这时使用 resize2fs 来扩展 ext4 文件系统：

bash复制sudo resize2fs /dev/sda2

如果根文件系统是 ext4，这条命令基本一次成功。如果在执行时提示文件系统有错误，先运行 sudo e2fsck -f /dev/sda2 修复后再执行 resize2fs。等到输出 The filesystem on /dev/sda2 is now 52428800 (4k) blocks long. 这样的信息，说明文件系统已经扩展完成。

最后验证一下：

bash复制df -h /

此时根分区的容量应该已经接近 200GB，而且 /dev/sda2 的使用量是连续的，Windows 侧的 ext4.vhdx 文件物理大小还是保持在之前的 20GB 级别。扩容的虚拟磁盘部分已经完成，操作系统里的空间已经拿到手了。

这里有个重要提示：在 expand vdisk 之后，一定要重新进入 WSL2 执行 growpart 和 resize2fs，而不要在 Windows 里用第三方分区工具去改 ext4 分区里又看不见文件系统。WSL2 内虽然也提供了 /mnt/c 的访问路径，但 ext4.vhdx 在 Windows 侧不是以可识别文件系统形式存在的，用 Windows 的 diskpart 只能识别“分区”，不能帮你把 ext4 分区“重新分配大小”。

4. 如果空间还是不够，如何安全地清理 WSL2 内部存储

扩容到 200GB 后，不代表从此高枕无忧，尤其是当你把 ROS、CUDA、Anaconda、Docker 全塞进去的时候，200GB 也会被慢慢啃食干净。我之前就遇到过扩充到 200GB 后不到半年又满的情况，原因是各种缓存和编译中间文件太多了。所以，清理习惯比扩容更重要。

4.1 apt 缓存和旧的 Linux 内核

Ubuntu 18.04 上 apt 下载的 deb 包缓存默认放在 /var/cache/apt/archives，如果长期运行 apt upgrade，这里可能会积攒几个 GB 的旧 .deb。清理方式：

bash复制sudo apt clean
sudo apt autoclean
sudo apt autoremove --purge

如果升级过内核，/boot 里很可能留着很多 linux-image-*-extra 旧版本，用 dpkg --list | grep linux-image 查询后，通过 apt 删除不需要的内核版本，再把 /boot 下的旧 initrd 一并清理。

4.2 pip/npm/cargo 等语言包缓存

bash复制pip cache purge
npm cache clean --force
rm -rf ~/.cache/pip ~/.npm ~/.cargo/registry

对于 ~/.cache 这一个目录，我就见过占了 15GB 以上的机器，大概率是各种语言包下载缓存和浏览器内核缓存堆积出来的。先看下 du -sh ~/.cache/* 找出大的挨个删。

4.3 Docker 镜像和 Build Kit 缓存

如果你在 WSL2 里跑了 Docker，docker system df 可以查看占用情况，docker system prune -a 可以清掉无用镜像、容器、网络、构建缓存。注意 -a 会把所有未被容器引用的镜像全部删除，如果你只想清理悬空镜像，去掉 -a 即可。

4.4 编译中间文件与 ROS 工作空间

ROS 的 catkin_ws/build 和 devel 是很吃空间的。经验法则是：源码没事别删，build 目录随便删。如果你现在不需要跑某些包，可以把 build 删除，下次 catkin_make 会重新生成：

bash复制cd ~/catkin_ws
rm -rf build devel

然后重新 catkin_make。这样做的代价是需要重新编译一次，但空间立省 10GB。注意 install 目录（如果你用了 catkin_make --install）也不能随便删，否则安装出去的可执行文件会失效。

5. 扩容后的 Windows 侧垃圾回收：如何压缩 ext4.vhdx

这大概是整个流程中最容易被忽略但最有用的步骤。你可能会想：我现在扩容到 200GB，我删除了 15GB 的缓存，为什么 C 盘剩余空间没有恢复？因为 VHDX 文件是“只涨不缩”的。即使你在 Ubuntu 内部删了东西，VHDX 文件物理大小不会自动收缩。你需要像整理衣柜一样，把空出来的“衣架”清理掉。

有两种方法可以压缩 VHDX：

方法一：在 WSL2 里用 fstrim 手动裁剪未使用块（推荐）

WSL2 里 fstrim 用于告诉底层存储，哪些块可以不再占用物理空间。在较新版本的 WSL2 上，你只需要在 Ubuntu 内部执行：

bash复制sudo fstrim /

但 Ubuntu 18.04 默认不一定会自动 trim。执行完之后，VHDX 文件的物理大小可能没有立即缩小，因为 Windows 层还需要做后续处理。你可以在 Windows 的 diskpart 里通过 compact vdisk 对它进行压缩，但前提是内部块已经被标记为可回收。这个操作是安全、无损的，不需要单独删除文件。

方法二：diskpart 的 shrink 或 compact VHDX

如果你想手动把 VHDX 从物理大小压缩到最小，需要按下面的流程执行：

1. 在 Ubuntu 内部先清理完垃圾文件。
2. 退出 WSL2，执行 wsl --shutdown。
3. 管理员权限打开 diskpart。
4. 只读挂载这个 VHDX：attach vdisk readonly。
5. 选择 select vdisk file=... 后执行 compact vdisk。

compact vdisk 会根据 VHDX 内部实际有效数据，重写文件并释放空洞，最后生成的 VHDX 物理体积会明显缩小。比如原来 20GB 的 VHDX，内部有效数据只有 8GB，compact 后可以缩到 8GB 左右。如果磁盘里有效数据已达 18GB，压缩效果就不太明显。

compact vdisk 的时间通常比较长，取决于数据量，可能从几分钟到十几分钟不等，中途请勿强制关闭窗口。执行完后，detail vdisk 可看到文件大小已减少，最后 detach vdisk 退出即可。

注意：执行 compact 前一定确认 WSL2 已经完全关闭，且在 diskpart 里选择的是正确的 vdisk。此操作对数据本身没有破坏性，但若在压缩中途断电或强制终止，有一定概率导致 VHDX 文件损坏。建议压缩前先做好备份（或至少把最重要的数据导出）。

6. 我踩过的几个真实坑，以及对应的排查思路

6.1 扩容前忘了 wsl --shutdown，diskpart 一直提示“虚拟磁盘正在使用中”

这是我第一次操作时犯的错误。我当时只是关闭了终端窗口，没有执行 wsl --shutdown。其实 WSL2 的后台进程还在运行，导致 attach vdisk 时 Windows 提示文件被占用。后来才明白，WSL2 的虚拟机实例不会因为你关闭所有终端就自动销毁，它有较长的“会话保持”机制，你要主动 wsl --shutdown 它才真正停止。

如果你执行了 wsl --shutdown 后仍然显示占用，可以用 PowerShell 检查相关进程：

powershell复制Get-Process | Where-Object {$_.ProcessName -like "*wsl*" -or $_.ProcessName -like "*vmwp*"}

看到有 vmwp.exe（虚拟机管理进程）时，可以通过 Stop-Process -Name vmwp -Force 强制停止，但如果实在不行，重启 Windows 是最稳妥的。

6.2 growpart 命令不存在，无法扩展分区

Ubuntu 18.04 的 cloud image 通常自带 cloud-init 和相关工具，但如果你是直接用 wsl --import 导入的镜像，可能不会默认安装 cloud-guest-utils。解决方法是直接安装：

bash复制sudo apt update && sudo apt install cloud-guest-utils

但问题在于，如果你的根分区已经 100% 满，apt install 往往因为写不进新文件而失败。此时你需要先清理空间：最简单的途径是看 journalctl 日志大小，或者清空 apt 缓存。如果这些都不行，还有一个救命稻草：你可以先把虚拟磁盘容量上限扩大（diskpart expand 到目标大小），然后重启 Linux，此时磁盘容量虽然变大，但文件系统还是 100% 满的，所以还是不能安装 cloud-guest-utils。怎么办？手动方式最靠谱：不装工具，直接用 parted 或 fdisk 也可以，但需要计算扇区。

其实还有个技巧：用 resize2fs 扩容时，其实不需要 growpart。因为如果根分区没有占据整个虚拟磁盘，Linux 的 resize2fs 只能扩展文件系统到分区大小，无法扩展分区本身。如果 fdisk -l 能看到磁盘总大小已经变大，但 /dev/sda2 分区大小没变，那你必须调整分区表。假如没有 growpart，可以这样用 parted 的非交互命令：

首先查看分区表情况：

code复制sudo parted /dev/sda print free

看 sda2 的 End 位置，分区后面是否有 Free Space。然后运行：

code复制sudo parted /dev/sda resizepart 2 100%

parted 会提示需要分区表被使用，确认一下即可，有可能需要指定 yes。之后执行 sudo resize2fs /dev/sda2。这个方法同样安全。

6.3 扩容后根分区没有增大，df -h 还是 20GB

如果你执行了 expand vdisk、growpart、resize2fs，最后 df -h 还是显示 20GB，大概率是漏了 resize2fs。注意 growpart 只改分区表，不改文件系统；resize2fs 负责改文件系统。两者缺一不可。

有些发行版还需要先执行 sudo e2fsck -f /dev/sda2 再 resize2fs。如果文件系统是 XFS 而不是 ext4，那就需要 xfs_growfs / 来扩展。不过 Ubuntu 18.04 默认根文件系统是 ext4，除非你当时手动改成了 XFS。

6.4 扩容后 ext4.vhdx 文件体积过大，且很难变小

这个问题就是 5.1 节说的压缩问题。有人用 wsl --shutdown 后直接把 ext4.vhdx 文件里的空洞删除，比如用某种工具将 VHDX 转成固定大小再转回动态，如果操作不熟练，极容易损坏数据。

正确且稳妥的顺序是：

1. Linux 内部清理垃圾。
2. wsl --shutdown。
3. diskpart 挂载为只读。
4. compact vdisk。

如果你在执行 compact vdisk 时因为磁盘空间不足而失败，需要先给 C 盘留出至少相当于 VHDX 物理大小 5%~10% 的可用空间，因为压缩过程可能需要临时空间存储元数据。如果这一步做不到，那你只能选择把 WSL2 迁移到另一个更大的分区，再压缩。

6.5 WSL2 里图形程序和 CUDA 环境在扩容后出现异常

扩容操作本身不应该影响已经安装的软件。但偶尔会遇到问题，比如 Linux 内核因为旧 initramfs 找不到新分区表，启动时出现 GRUB 或 kernel panic。这种情况多发生在直接修改过 Windows 侧启动引导的机器上，对 WSL2 来说通常不太可能，因为 WSL2 内核是 Windows 直接加载的，不依赖 Ubuntu 的 GRUB。如果你启动不了 WSL2，可以执行 wsl --shutdown，再打开 Windows 服务确认 LxssManager 处于运行状态。

另一个常见异常是在扩容后，Docker Desktop 的 WSL 集成突然失效，原因是 Docker Desktop 重新检测 WSL 发行版时读取的分区信息未刷新，此时最简单的方法是重启 Docker Desktop 和 WSL 服务。

其实大多数扩容后“系统起不来”的情况，不是扩容操作本身搞坏了系统，而是之前 attach/detach VHDX 时没有按照规范做，导致 VHDX 元数据里的分区状态不一致。所以，建议你在每次 Windows 侧修改过 VHDX（比如 attach 或 compact）之后，都先运行一次：

bash复制sudo fsck -f /dev/sda2

如果检测通过，再进去系统正常使用，这样就非常稳妥了。

7. 结合工作流实际，给出一个裸机可抄的完整操作清单

如果你只想照着流程快速完成，这里总结成一个带权重的实战清单，建议按照顺序执行：

这个顺序是有讲究的。比如先压缩后扩容、或者先扩容后不用 growpart，都会造成 VHDX 最大容量变大了但分区表没变，最终你在 Linux 里还是无法写入更多数据。很多教程的误区在于只是告诉你用 diskpart 或第三方工具调整分区大小，但忽略了 WSL2 里根分区的“文件系统大小”不等于“磁盘最大容量大小”这个细节。

8. 扩容完之后，日常使用还能做点啥

扩到 200GB 或 500GB 空间后，不用再时刻担心磁盘满，但做好空间规划，能避免日后再折腾一次。

8.1 把 Docker 的数据根目录迁到 Windows 的 D 盘

如果你在 WSL2 里使用 Docker，默认的 Docker 数据目录位于 WSL2 的发行版内部，比如 /var/lib/docker。你可以在 Docker Desktop 的设置里，把 disk image location 改成 D 盘的某个目录，这样镜像和容器卷的数据不会占用 WSL2 虚拟磁盘空间，也就从源头上避免了撑爆 WSL2。如果用的是纯 Linux 版 Docker（没有 Docker Desktop），则可以通过修改 /etc/docker/daemon.json 中的 data-root 指向 /mnt/d/docker-data，然后重启 Docker。

8.2 将大型数据集和模型放在 /mnt 下的 Windows 目录

WSL2 访问 /mnt/d 这类 Windows 挂载路径时性能会比直接访问 ext4 文件系统慢一些，但对于读取模型训练、图片数据集这类顺序读操作，性能问题其实并不是太严重。为了减小 WSL2 虚拟磁盘的负担，可以把大数据集放在 D:\datasets，然后在 WSL 里建立一个软链接到你的工程目录，例如：

bash复制ln -s /mnt/d/datasets/object_detection ~/datasets

这样做的好处是数据不会占用 ext4.vhdx 的空间，Windows 杀毒软件也能直接扫描到，备份起来也方便。

8.3 建一个脚本化的一键压缩流程

我相信你会和我一样，几次扩容、几次压缩之后，形成一套肌肉记忆。建议直接写一个 PowerShell 脚本，以后清理完磁盘后一键运行：

powershell复制# 请先修改为你自己的发行版 ext4.vhdx 路径
$vhdxPath = "C:\Users\<用户名>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc\LocalState\ext4.vhdx"

# 停止所有发行版
wsl --shutdown

# 用 diskpart 压缩虚拟磁盘
$diskpartScript = @"
select vdisk file="$vhdxPath"
attach vdisk readonly
compact vdisk
detach vdisk
exit
"@

$diskpartScript | diskpart

Write-Host "压缩完成。请重新打开 WSL2。"

把脚本保存为 .ps1，每次清理完 WSL 内部垃圾后，先在 Ubuntu 里执行一次 sudo fstrim /，再以管理员身份运行这个脚本，Windows 侧的磁盘空间就能真正回归。

我在实际使用中发现，很多人对 WSL2 的空间容量都有一种误解，觉得它不像虚拟机一样需要单独划分分区，而是会自动按需扩展。理论上是这样，但前提是你要懂得主动去把虚拟磁盘的上限调整到一个足够大的值。默认的 20GB 在上古时代可能够用，放到现在的开发环境（CUDA、ROS、Docker、数据集）里完全没法打。所以，每月月初检查一下 df -h 和 C 盘剩余空间，如果 C 盘出现常年不足，趁早把 WSL2 发行版迁移到 D 盘然后在 D 盘扩容，这样可以让你以后少受罪。

不管怎样，用 diskpart 加 growpart 这套扩容方式，能绕过导出/导入的漫长等待，也不用担心发行版重装导致的配置丢失。只要按照“先备份、再 shutdown、挂载为只读、扩展上限、调整分区、扩展文件系统、压缩回收”这条思路走，即使你的根分区已经 100% 满了也能被安全解救回来。当然，如果你只是为了跑跑 hello world 型的实验，那 20GB 扩容到 50GB 可能足够了，没必要为了扩容而扩容，虚拟磁盘文件动态膨胀之后，Windows 系统盘的清理压力还是会回来的。祝你扩容顺利，别再被 No space left on device 卡住一下午。