装完WSL之后用了一两个月C盘突然就爆红了这种事情我身边已经有好几个人遇到过。原因不外乎那几样Python虚拟环境、PyTorch的模型缓存、apt装了一堆依赖再加上Docker镜像WSL的虚拟磁盘文件就跟吹气球一样长到了几十个GB。再加上WSL本身默认装在C盘Windows的临时文件、页面文件也都在C盘最后的结果就是系统卡到怀疑人生。我最初解决这个问题的办法很粗暴直接卸载重装。但后来发现WSL的发行版数据其实就是一个虚拟磁盘文件把这块硬盘从C盘搬到其他盘完全不需要重装系统也不需要重新配置环境。整个过程十几分钟就能做完而且还能顺手把WSL的虚拟磁盘压缩一遍等于同时完成迁移和瘦身两件事。这篇文章就是把我的完整操作流程、踩过的坑和几个隐藏在细节里的知识点一起整理出来照着做就能搞定。注意以下操作适用于WSL2。Windows 102004及以上和Windows 11均可命令在PowerShell中执行。1. 先搞明白WSL的存储机制C盘为什么会被吃干净1.1 WSL的系统盘其实是一个文件很多人对WSL有个误解以为它像虚拟机一样会创建一个单独的分区。其实WSL2的整个Linux文件系统包括/bin、/home、/usr下面所有东西都存放在一个特殊格式的虚拟磁盘文件里文件名一般是ext4.vhdx。默认情况下这个文件藏在当前用户的AppData目录里具体路径是C:\Users\你的用户名\AppData\Local\Packages\发行版包名\LocalState\ext4.vhdx其中发行版包名对于Ubuntu来说通常是CanonicalGroupLimited.Ubuntu...这样的结构不同版本略有差异。也就是说你在WSL里创建的文件、安装的软件包、Python环境、模型文件本质上全都进了这一个文件里。Linux里的磁盘占用在Windows侧就表现为这一个文件的大小。理解了这一点迁移思路就非常清晰了——我们要做的事就是把整个ext4.vhdx的内容搬到D盘或者其他空间充足的位置然后让WSL指向新的文件位置。1.2 vhdx只增不减的膨胀逻辑WSL2用的vhdx是动态扩展的虚拟磁盘格式。什么叫动态扩展就是它一开始只有几百MB随着你往里面写入数据文件会逐渐变大。但问题在于你在WSL里删除文件之后vhdx文件并不会自动缩小。我给打个比方你往这个虚拟硬盘里塞了50GB的数据后来删了30GB但在Windows文件管理器里看ext4.vhdx依然是50GB左右。那些被删除的数据块虽然在Linux视角下已经释放了但虚拟磁盘文件本身不会把那部分空间交还给C盘。这就是为什么很多人的C盘会被WSL慢慢吃干净——明明在WSL里df -h显示只用了20GB但Windows侧的文件却占了60GB。也正因为这个机制手动重新导出再导入相当于把数据重新打包成新的虚拟磁盘那些空闲空间就会被剔除掉。所以迁移WSL和压缩WSL磁盘经常是同一个操作一次搞定。1.3 迁移的本质导出tar再导入WSL官方提供了两个命令wsl --export和wsl --import专门用于迁移和备份。它们的原理很简单wsl --export把整个Linux文件系统打包成一个tar文件类似把整块硬盘做成镜像wsl --import读取这个tar文件在新的位置生成一个新的vhdx并注册到WSL。这种做法有几个好处迁移过程不依赖vhdx当前是否膨胀打包出来的是实际数据同时迁移后生成的vhdx按需增长已经释放的空闲空间不会再占地方。无论你原来的vhdx被撑大到500GB还是800GB只要其中实际数据只有40GB导出的tar包也就是40GB左右导入到新盘后新生成的vhdx同样在40GB左右。这一步对于被WSL磁盘膨胀困扰的人来说简直就是一次免费的磁盘清理。2. 迁移前的摸底三个命令看清当前状态不管做什么系统级的操作我都习惯先摸清楚现状再动手。迁移WSL之前用下面三个命令把当前的发行版信息和磁盘占用情况搞明白。2.1 查看当前WSL发行版列表在PowerShell中执行wsl --list --verbose或者用缩写形式wsl -l -v输出结果类似NAME STATE VERSION * Ubuntu Stopped 2这里NAME就是发行版名称迁移的时候要用VERSION必须要是2也就是WSL2否则后续的操作逻辑会有差异。如果显示的是1建议先升级到WSL2再继续。这一步别跳过。很多人迁移失败就是因为连发行版名称都没确认在导出的命令里写错名字白白浪费了时间和流量。2.2 找到当前vhdx文件的精准位置在WSL里执行df -h /能看到Linux根目录挂载在哪个设备上但那只是Linux视角。要找到Windows侧的物理文件位置用文件资源管理器访问\\wsl$\发行版名\或者直接在PowerShell里这样定位Get-ChildItem -Path $env:LOCALAPPDATA\Packages -Filter ext4.vhdx -Recurse | Select-Object FullName, {NameSizeGB;Expression{[math]::Round($_.Length/1GB,2)}}这样能直接列出所有WSL发行版对应的vhdx文件路径和大小一清二楚。我之前就因为装了多个发行版搞混了哪个对应哪个后来就是用这条命令彻底搞明白的。2.3 评估目标盘空间和导出盘空间迁移之前必须算一笔账目标盘比如D盘必须有足够空间容纳迁移后的新vhdx导出tar文件也需要一个临时位置最好和目标盘在同一个盘符下因为导出完之后如果确认没问题tar包可以直接删掉不会多占一份空间。一般来说目标盘的空闲空间至少要大于当前vhdx中实际数据量加上一部分余量。如果tar包本身就要放在目标盘那么目标盘的空余空间至少要等于实际数据量的两倍tar包一份新vhdx一份。实际数据量怎么看在WSL里执行du -sh / --exclude/proc --exclude/sys --exclude/dev --exclude/mnt这个值会比Windows侧看到的vhdx文件大小小很多因为vhdx包含了膨胀的空闲空间。3. 完整迁移流程导出、注销、导入、恢复下面的流程就是我在多次实践中觉得最稳妥的顺序。有人可能会想先导入新的再删旧的然而这样容易碰同名冲突的坑所以我把推荐顺序排列如下3.1 第一步关闭WSL释放文件锁wsl --shutdown这个命令会立刻终止所有正在运行的WSL发行版。这一步不能省否则ext4.vhdx正在被占用导出或者移动文件时会报权限错误。执行完可以再跑一下wsl -l -v确认所有发行版都处于Stopped状态。如果你在WSL里还开着什么长驻服务先手动保存一下数据毕竟wsl --shutdown相当于直接断电关机的效果。3.2 第二步导出当前发行版为tar包使用wsl --export命令导出。命令的基本格式wsl --export 发行版名称 目标tar文件路径举例把名为Ubuntu的发行版导出到D盘的临时目录wsl --export Ubuntu D:\wsl-backup\ubuntu-backup.tar导出过程视数据量大小耗时从几分钟到几十分钟不等过程中PowerShell窗口会一直处于繁忙状态没有任何进度条这是正常的耐心等待就好。如果导出过程中报错最大可能是目标路径不存在或者磁盘空间不足。这里有个小技巧导出后的tar包其实就是一个完整的系统备份所以即使你暂时不打算迁移定期导出一次放在其他盘上也算是一个保险措施。万一WSL哪天被弄坏了用wsl --import分分钟恢复回来。3.3 第三步注销旧发行版确认tar包导出完成且大小合理后执行wsl --unregister Ubuntu注意这一步需要谨慎操作。--unregister会删除该发行版在WSL中的注册信息并删除关联的vhdx文件也就是说你在WSL里的所有数据都会从C盘彻底移除。所以要确保上一步导出的tar包是完好的再执行这条命令。如果不放心可以先看一眼tar包文件大小再和WSL里du -sh的数据对比一下数量级符合预期就基本没问题。执行成功后C盘的那一大块占用基本就释放出来了。3.4 第四步导入到目标盘现在用wsl --import命令把tar包恢复到新的位置wsl --import 发行版名称 目标安装目录 tar包路径 --version 2举例把之前导出的Ubuntu恢复到D盘wsl --import Ubuntu D:\WSL\Ubuntu D:\wsl-backup\ubuntu-backup.tar --version 2这里D:\WSL\Ubuntu是新的安装目录导入后会在该目录下生成一个ext4.vhdx文件。如果这个目录不存在命令会自动创建。导入完成后你可以在D:\WSL\Ubuntu\ext4.vhdx确认新vhdx文件的大小。这时候你会惊喜地发现相比原来C盘上那个几十GB甚至上百GB的文件新文件的体积明显小了一大截这就是动态扩展磁盘重新整理之后的效果。3.5 第五步恢复默认用户导入完成后直接启动WSL会发现默认用户变成了root。这是wsl --import导入的常见副作用因为tar包镜像虽然保留了原来的用户数据和权限但WSL的默认用户配置不会跟着过来。如果你用的是Ubuntu发行版最简单的恢复方法是直接编辑WSL的配置文件。先启动WSL进入系统wsl -d Ubuntu然后在WSL内部执行echo -e [user]\ndefault你的用户名 | sudo tee /etc/wsl.conf把你的用户名替换成你原来在WSL里的用户名。写完退出WSL再执行一次wsl --shutdown重新进入就又变回原来的用户了。如果不记得用户名可以查看/home目录下有什么ls /home那里面基本就是你原来的用户名。3.6 验证迁移结果启动WSL后挨个检查自己常用的环境是否正常确认Python环境还在python --version确认conda环境还在conda env list确认之前安装的软件服务能正常启动systemctl status或者直接尝试启动确认文件数据都在ls ~另外可以检查一下Windows侧新vhdx的位置和大小Get-ChildItem D:\WSL\Ubuntu\ext4.vhdx确认无误后导出的tar包就可以删掉了。我个人习惯是留着它等到新环境稳定运行一周后再删。这样万一迁移后有什么不兼容的地方还有回滚的余地。4. 迁移后的两个必做动作清理残留和防止再次膨胀迁移完成只是第一步收尾工作做不好过阵子又会陷入空间告急的循环。我总结了两个必做的收尾动作。4.1 确认旧发行版空间真的释放了正常情况下wsl --unregister会同时删除C盘上原来的ext4.vhdx文件。但这个文件有时候不会立刻消失尤其是在Windows资源管理器还开着旧路径的时候。如果注销后C盘空间没有明显变化建议这样排查Get-ChildItem -Path $env:LOCALAPPDATA\Packages -Filter ext4.vhdx -Recurse -ErrorAction SilentlyContinue如果还能看到残留的vhdx文件说明删除没有完成。这时候手动删除即可注意路径核对清楚不要误删了其他发行版的文件。删除前最好重启一次WSL服务或者重启资源管理器确保没有进程占用。4.2 用diskpart压缩新盘的vhdx迁移到新盘之后vhdx一开始是干净的。但随着日常使用它照样会膨胀。等你发现D:\WSL\Ubuntu\ext4.vhdx又变成好几十GB的时候可以手动压缩一次。WSL必须完全关闭wsl --shutdown然后以管理员身份打开PowerShell进入diskpartdiskpart在diskpart交互界面中依次输入select vdisk fileD:\WSL\Ubuntu\ext4.vhdx attach vdisk readonly compact vdisk detach vdisk exit解释一下这几条命令的作用attach vdisk readonly以只读方式挂载虚拟磁盘这样可以在不启动WSL的情况下安全访问它compact vdisk这是核心命令把虚拟磁盘中未使用的空闲空间回收掉相当于给磁盘做了碎片整理和压缩detach vdisk解除挂载确保操作完成后磁盘状态正常。整个过程通常几十秒到几分钟。结束后再看vhdx文件大小又能瘦下去一圈。我每过两三个月就会做一次这个操作配合下面的日常清理基本不会出现空间告急的情况。4.3 顺手排查哪个目录最吃空间迁移后正好是一起做系统大扫除的时机。登录WSL后用du命令看看哪里占用最大du -h --max-depth1 /home 2/dev/null | sort -hr | head -20 du -h --max-depth1 /usr 2/dev/null | sort -hr | head -20如果你是重度用户以下几个目录通常是大头~/.cachepip、conda、apt的缓存可能占好几个GB~/.conda/pkgsconda安装包缓存/var/lib/dockerDocker的镜像和容器数据~/.local/share/TrashLinux图形环境下的回收站。针对不同目录有对应的清理命令sudo apt clean sudo apt autoremove pip cache purge conda clean --all docker system prune -a这些清理命令在迁移后做一遍能让新盘的vhdx保持在一个相当精简的状态。5. 迁移过程中容易翻车的细节与排查思路迁移流程看着就几条命令但实际操作中总会遇到各种幺蛾子。我把亲身踩过的和帮别人排查时遇到过的几类高频问题列出来方便你卡住的时候逐一对照。5.1 导出失败先看盘符路径和权限我最早遇到的问题是wsl --export提示找不到路径。原因是PowerShell当前工作目录在C盘而我把目标写成了相对路径。后来统一使用绝对路径就再没碰到过。另一个常见问题是目标盘是U盘或者NAS网络驱动器这种场合文件系统可能不支持大文件写入或者写入速度极慢。如果遇到导出长时间卡住不动先检查目标位置是不是NTFS格式而且要有足够的连续空间。5.2 导入后WSL里没有原来的用户wsl --import导入后默认进入的是root用户而且经常出现/home/用户名下文件确实都在但你不知道用什么命令切换到那个用户的情况。我推荐的解决方案就是前面讲的/etc/wsl.conf配置法echo -e [user]\ndefault你的用户名 | sudo tee /etc/wsl.conf写完后重启WSL默认用户就回来了。这个方法在Ubuntu、Debian、Kali等主流发型版上都通用不用依赖发行版自带的exe命令。5.3 迁移后网络异常代理配置残留如果你之前在WSL里配置过HTTP代理比如给命令行工具加速用迁移后可能会发现网络请求变慢甚至直接失败。常见报错信息里会出现detected localhost proxy configuration, but not mirrored to WSL类似字样。这是因为Windows侧的代理设置和WSL2的NAT网络模式之间存在兼容性问题。排查思路很直接检查WSL里的环境变量env | grep -i proxy如果看到http_proxy、https_proxy之类的变量还指向旧的代理地址要么更新为有效的代理端口要么在/etc/wsl.conf中关闭相关配置或者把Windows侧的代理设置暂时关闭再重启WSL测试。如果这个代理是业务必用的推荐在Windows用户目录下创建一个.wslconfig文件写入[wsl2] networkingModemirrored镜像网络模式下WSL会直接共享Windows的网络栈比NAT模式少很多转发和隔离问题。不过需要Windows 11 22H2以上版本才支持Windows 10用户就只能继续用NAT模式遇到代理问题时手动调整WSL里的代理变量。5.4 导入后磁盘空间比预期大很多有朋友遇到过迁移后新vhdx居然还是几十GB和原来几乎一样。这种情况通常不是迁移失败而是因为tar包导入时保留了一些特殊的稀疏文件或者文件系统元数据。解决方案是再做一次节4.2的vhdx压缩流程。如果压缩后还是很大说明你的数据里确实有大量文件比如大模型权重、数据集那就属于正常情况了。这种时候更应该关注是否有必要把大文件单独放到Windows侧挂载目录/mnt/d/...来管理避免写入WSL的虚拟磁盘。6. 从根源上规避新装场景还有其他更快的迁法如果你还没开始用WSL或者准备在另一台电脑上重新部署下面两种方式也能达到目的而且比导出导入更省事。6.1 全新安装时直接指定目标盘WSL默认安装在C盘但新装的发行版可以在安装时指定位置。用wsl --install命令安装的发行版默认依然在C盘不过你可以先安装然后用前面导出导入的方法迁移。如果你不想走两遍流程可以在应用商店安装发行版后从设置里查看移动入口部分发行版的后台应用支持直接移动到其他盘。不过说实话最快最可靠的方式还是老老实实导出-注销-导入这个方法对任何发行版都生效不受应用商店的限制。6.2 更高阶的直移法--import-in-place如果你的WSL版本比较新WSL 1.2.0以上还可以用--import-in-place参数直接把现有的vhdx文件移动到新位置然后注册。它的执行步骤是wsl --shutdown关闭所有实例手动把整个发行版目录包含ext4.vhdx的那个文件夹从C盘剪切到D盘执行wsl --unregister Ubuntu wsl --import-in-place Ubuntu D:\WSL\Ubuntu这个方式比导出再导入快很多因为它省掉了打包和重新生成vhdx的时间只是把虚拟磁盘文件搬了个地方再重新注册。但注意它的弊端没办法对vhdx做瘦身原本膨胀的空间还会继续保留。如果C盘已经告急单纯移动解决了位置问题但磁盘空间的浪费依然存在。所以我的建议是如果只是腾位置不在乎vhdx膨胀问题优先用--import-in-place速度快如果既想腾位置又想给虚拟磁盘瘦身走完整的导出-注销-导入流程。6.3 重度使用者的空间管理建议迁移完成只是阶段性的胜利如果继续无节制地往WSL里装东西过几个月还是会把新盘塞满。我和WSL共处的这几年的经验是大数据文件尽量放到Windows侧访问WSL里通过/mnt/d/...直接引用不要复制进WSL的虚拟磁盘Python和conda的缓存定期清理尤其是经常测试新包的人~/.cache和conda的pkgs目录是最容易悄悄膨胀的地方习惯性跟踪vhdx大小在PowerShell里把查看ext4.vhdx大小的命令存成一个别名每次系统卡顿时顺手看一眼每季度做一次wsl --shutdown加compact vdisk的维护操作整个过程不超过五分钟但能保证虚拟磁盘长期处于合理大小。按这套方法来管理WSL的存储问题基本不会再成为你的困扰。迁移这件事真正麻烦的不是命令本身而是对WSL存储模型的正确理解。搞清楚了ext4.vhdx就是一个会膨胀的虚拟磁盘文件很多问题都能迎刃而解。我实操下来的总体感受是尽早迁移、定期维护、把大数据隔离在WSL之外这三件事做到WSL用起来真的会省心非常多。