WSL迁移出C盘：ext4.vhdx虚拟磁盘的完整导出导入与空间释放指南

C盘又红了。相信不少人和我一样第一反应是去翻C:\Users下的缓存和临时文件清完了没两天又满了最后逐一排查才发现真正的大户是 WSL——尤其是 WSL2它会慢慢“吞”掉几十甚至上百GB。很多人想直接把 WSL 从 C 盘拖到 D 盘却卡在“系统提示文件被占用”“不知道哪些文件能移”“迁移完默认用户变成 root”这些细节上。这篇文章就把 WSL 迁出 C 盘的完整流程、背后原理和常见坑一次讲清楚适合已经装好 WSL、但被 C 盘空间折腾得不行、又不想重装系统的开发者参考。1. 迁移前先弄清 WSL 的“家底”它到底把什么放在了 C 盘想迁移先得知道 WSL 在 C 盘存了什么东西。很多人以为 WSL 是“装在 Windows 里的一个 Linux 程序”删了重装就行但这会丢掉所有 Linux 内部的数据和配置。实际上WSL 的发行版数据全部打包在一个虚拟磁盘文件里搞清楚这一点后续操作就顺理成章了。1.1 发行版本体一个不断膨胀的 ext4.vhdxWSL1 和 WSL2 的存储机制完全不同。WSL1 是系统调用翻译层文件直接落在 Windows 目录里散落一地WSL2 则是跑在一个轻量级虚拟机里整个 Linux 文件系统被封装成一个ext4.vhdx虚拟磁盘文件。默认情况下每个从 Microsoft Store 安装的发行版都会在 C 盘用户目录下建一个独立的包文件夹路径大致是C:\Users\你的用户名\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu22.04...\LocalState\ext4.vhdx不同发行版对应的包名不一样Ubuntu 是CanonicalGroupLimited开头Kali 是KaliLinuxDebian 是TheDebianProject。你不需要记得这些完整路径直接在 PowerShell 里执行下面这段命令就能列出所有ext4.vhdx的位置和大小Get-ChildItem -Path C:\Users\$env:USERNAME\AppData\Local\Packages -Recurse -Filter ext4.vhdx -ErrorAction SilentlyContinue | Select-Object FullName, {NSizeGB;E{[math]::Round($_.Length / 1GB, 2)}}你会看到这个文件可能有十几到几十GB。它就是你 Linux 里的/home、/etc、/usr、所有源码、数据库、conda 环境的全部家当。迁移 WSL 的本质就是把这个 vhdx 挪到别的盘并让 Windows 正确识别到它。1.2 Docker Desktop 的数据也会占 C 盘如果你的 Docker Desktop 使用的是 WSL2 后端默认就是那还要注意Docker 的镜像、容器、卷数据也存在 WSL 的发行版里通常对应docker-desktop和docker-desktop-data这两个发行版它们的 vhdx 路径同样在 C 盘的 Packages 目录下。所以迁移之前我建议你先执行wsl -l -v把所有发行版列出来看看别只盯着 Ubuntu 一个。很多人迁完了 Ubuntu发现 C 盘空间只腾出来一半另一半在 docker-desktop 那边还得再搞一轮。wsl -l -v输出类似NAME STATE VERSION * Ubuntu-22.04 Running 2 docker-desktop Stopped 2 docker-desktop-data Stopped 2如果你的核心痛点是 Docker 镜像太多那你也得决定是连 docker-desktop-data 一起迁还是干脆把不需要的 docker 发行版注销掉。这个问题在迁移前就要想清楚不要导到一半才发现目标盘空间不够。1.3 为什么不能直接剪切 ext4.vhdx很多人会问那我直接把这个 vhdx 文件剪切到 D 盘然后在原来的位置建个快捷方式行不行答案是系统不一定认你这一套。WSL 发行版的注册信息保存在 Windows 注册表里具体位置是HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss每个发行版对应一个以 GUID 命名的子键里面记录了发行版名称、版本1 还是 2、以及最重要的BasePath——也就是它认为的“发行版数据目录”。当你启动 WSL 时系统会按注册表里的BasePath去找ext4.vhdx而不是智能地全盘扫描。所以单纯剪切文件而不改注册表启动时大概率会报找不到发行版或者干脆显示发行版已损坏。而直接改注册表也不是不行但风险高、容易把环境搞出不可逆的问题。最稳妥、被官方认可的做法就是用wsl --export导出成备份文件再通过wsl --import导入到新位置。这套流程对新手来说也是最不容易翻车的。1.4 迁移前预检空间、文件系统、备份动手之前花两分钟确认三件事检查项要求说明目标盘可用空间≥ 当前 vhdx 实际大小 5GB导出 tar 时可能还会占用空间留足余量目标盘文件系统NTFS 或 ReFSFAT32 单文件不能超过 4GBvhdx 动辄几十GB不行C 盘临时空间尽量保留与 vhdx 大小相近的空间导出 tar 默认会先写在你指定的路径如果 C 盘实在不够就把 tar 直接导出到 D 盘另外迁移虽然不会主动破坏数据但谁也不能保证断电、系统更新、磁盘故障这些意外不会发生。我建议在正式操作前先用导出命令生成一份完整的 tar 备份这本身就是迁移流程的第一步同时也是一份保命备份。导出完成后如果后续每一步都顺利这份 tar 还可以作为日常备份留存如果出了岔子也可以随时用它在任意盘符恢复相当于给自己的 Linux 环境上了一道保险。2. 主线操作wsl --export 与 wsl --import 的完整迁移链路到这一步你只要照着命令敲就能完成迁移。我用一个名为Ubuntu-22.04的发行版作为示例你自己的发行版名字以wsl -l -v输出为准。需要注意WSL 命令不区分大小写但发行版名称是精确匹配的建议直接复制控制台里的名字。2.1 第一步确认当前发行版名字和状态打开 PowerShell 或 Windows Terminal先执行wsl -l -v把输出里要迁移的发行版名称记下来。如果名称里有空格比如Ubuntu-22.04没有但某些自定义发行版可能有后面所有命令里都要用双引号包住这个名字。同时确认这个发行版当前是 Running 还是 Stopped。一般来说只要你的终端里没开着 WSL 会话它可能是 Running也可能因为后台服务比如 Docker、VS Code Remote-WSL被唤醒。别急下一步专门处理它。2.2 第二步彻底关闭所有 WSL 会话很多人的习惯是关掉终端窗口就算完但 WSL2 的后台进程并不会因为你关窗口就立刻退出。如果你在 Linux 里跑了 node、python 或者 systemd 服务整个虚拟机会继续保持运行状态。直接在这个状态下操作轻则导出文件不完整重则导致 vhdx 文件被锁定。正确姿势是执行wsl --shutdown然后等两三秒再执行一次wsl -l -v确保目标发行版状态是Stopped。如果发现还是 Running可以在任务管理器里看看有没有wslhost.exe或vmmemWSL进程或者再执行一次wsl --shutdown。这一步是整条链路的地基地基没打牢后面会很难受。2.3 第三步导出为 tar 备份现在可以导出发行版了。在 PowerShell 里执行wsl --export Ubuntu-22.04 D:\wsl-backup\ubuntu-22.04.tar这里我把 tar 直接放到了 D 盘免得 C 盘空间雪上加霜。注意D:\wsl-backup这个目录要提前建好否则命令会报路径不存在。导出时间取决于你的 vhdx 大小和磁盘速度我迁过一个 30GB 的发行版大概花了 10 多分钟过程中控制台没有进度条看着像卡住但只要没报错耐心等就行。有些较新的 WSL 版本支持追加--vhd参数直接导出为 vhdx 格式镜像不过 tar 是最通用、最不容易出问题的格式我建议新手上路就用 tar。导出完成后可以到对应目录看看文件大小一般会比 vhdx 略小一些因为 tar 会对空闲块做一定程度的优化。2.4 第四步注销原发行版确认 tar 文件已经完整生成之后就进入“不可逆”的环节了。执行wsl --unregister Ubuntu-22.04这里我要把丑话说在前面unregister不是“从列表里拿掉入口”而是把这个发行版的所有数据全部删除。执行完之后C 盘那个 ext4.vhdx 文件会被删掉注册表里对应的条目也会被清除。如果上一步没有成功导出或者导出文件是坏的执行这一步等于亲手删库。只有--export成功、且你确认 tar 文件存在且大小合理之后才能继续。注销完成后可以用wsl -l -v看看列表里已经没有这个发行版了再检查一下 C 盘空间有没有释放。2.5 第五步在新盘符上导入先创建目标目录New-Item -ItemType Directory -Path D:\WSL\Ubuntu-22.04然后执行导入wsl --import Ubuntu-22.04 D:\WSL\Ubuntu-22.04 D:\wsl-backup\ubuntu-22.04.tar --version 2参数从左到右分别是发行版名称、导入目标位置、tar 文件路径、WSL 版本。这里明确指定--version 2确保导入进来还是 WSL2如果这一步漏了有些旧版本默认会导入成 WSL1文件系统行为会变。导入命令执行完发行版会自动启动一次进行文件系统初始化。你可以再用wsl -l -v看看状态确认已经注册成功且BasePath指向了 D 盘。2.6 第六步修复默认用户这是整个流程里大家抱怨最多、也最容易忽略的一步。wsl --import导入的发行版默认登录用户是 root。很多人迁移完一打开终端发现提示符变成了#第一反应是“我的用户名哪去了我的 home 目录怎么怪怪的”修复方法有两种。第一种在 Linux 内部配置。先用 root 登录创建或修改/etc/wsl.conf[user] default你的用户名然后回到 Windows执行wsl --shutdown重新打开 WSL默认用户就恢复正常了。第二种如果你还记得用户名也可以直接执行发行版自带的配置工具比如 Ubuntu 系ubuntu2204 config --default-user 你的用户名不同发行版的工具名不一样而且有些发行版在 import 后这个工具不一定出现在 PATH 里所以我个人更推荐第一种方法写进wsl.conf最通用。注意wsl.conf里这个[user]小节只在 WSL2 的较新版本里生效操作完了一定要wsl --shutdown再重启否则不会重新读取配置。3. 导入后恢复现场默认用户、目录权限与常用工具链迁移成功的标志不只是“能打开终端”而是你的开发环境还在、配置还在、工具链还能照样跑。这个章节就是把现场仔细检查一遍别等用到的时候才发现少了东西。3.1 逐个确认文件完整性与磁盘挂载重新进入 WSL 后先执行几个最基本的命令whoami pwd ls -la ~ df -hwhoami用于确认默认用户是否已恢复正常df -h可以看到根文件系统的容量是否和迁移前一致ls -la ~则是快速查看 home 目录下的文件有没有丢。我遇到过一次导入后目录在但 dotfile比如.bashrc、.ssh权限变成了-rw-r--r--导致 SSH 直接拒绝加载私钥提示权限太开放。所以在检查文件的时候顺手执行一遍chmod 700 ~/.ssh chmod 600 ~/.ssh/*还要检查一下之前的固定挂载点。如果你更改过/etc/fstab或者/etc/wsl.conf里的 automount 配置导入后这些配置文件是保留的但如果 Windows 侧路径发生了变化这次迁移不涉及 Windows 用户目录变化一般没问题还是要确认/mnt/c、/mnt/d这些挂载是否正常。3.2 VS Code Remote-WSL 与 Windows Terminal 的适配迁移前用 VS Code 连过 WSL 的话迁移后在 VS Code 里执行code .可能会发现它重新弹出一个新窗口或者提示连接已断开。这是正常现象因为 WSL 发行版的实例 GUID 变了VS Code 需要在新的实例上重新安装 server 组件。做法是在 VS Code 里重新“Connect to WSL”让它重新选择一个发行版然后打开一个 WSL 路径下的文件夹它就会自动在新位置部署 Remote Server。Windows Terminal 一般不用做额外配置因为配置文件的启动命令通常是wsl.exe -d Ubuntu-22.04它按发行版名称查找不会因为注册表 GUID 变了就失效。但如果你在 Windows Terminal 里自定义过图标、启动目录最好看一眼。还有个小细节有些人的 wsl.conf 里设置了[automount] root...或者默认工作目录的打开方式迁移后如果之前自定义过cd起始目录也一并确认下。3.3 符号链接、环境变量与 systemd 服务tar 导出导入理论上会保留 Linux 侧的符号链接和软链接symlink所以/usr/bin/python指向python3这类链接通常没问题。但如果你曾经在 Windows 侧用编辑器打开过 Linux 里的文件某些文件可能被自动加上 CRLF 换行或者权限被 Windows 侧“同化”导致二进制文件或脚本出现异常。比如.sh脚本突然报bad interpreter或者git提示file mode changed多半就是权限位变化。环境变量不用重配因为/etc/profile.d、~/.bashrc、~/.zshrc这些文件都原封不动地在新 vhdx 里。systemd 也一样如果你之前开启了systemdtrue它会随配置保留导入后首次启动可能稍微慢一点属于正常初始化。3.4 Docker 内部工具链的状态检查如果你不是在 Docker Desktop 里用 WSL而是在 WSL 内部自己装了 docker-ce迁移后要确认 dockerd 能正常启动。很多时候迁移本身不会破坏 Docker 的数据目录默认在/var/lib/docker但 daemon 配置里如果写死了某个 overlay 挂载点可能会因为启动顺序问题短暂失败。最简单的验证方式service docker start docker ps如果 Docker 是 Docker Desktop 管理的那就要回到第 1.2 节说的你可能还得处理 docker-desktop-data 发行版或者至少确认 Docker Desktop 能为新迁移的发行版重新创建后端。4. 验证与瘦身确认 C 盘已释放并解决 VHDX 只增不减的问题迁移完成了环境也恢复了但还没到收工的时候。这一步要做的是确认 C 盘空间真的回来了同时解决一个很多人都会遇到的隐性坑——vhdx 文件只增不减。4.1 迁移成功后的铁证验证打开“此电脑”看看 C 盘可用空间是不是比迁移前增加了几十GB。也可以直接在 PowerShell 里对比迁移前后剩余空间Get-PSDrive C | Select-Object Used, Free如果 C 盘空间没有明显增加不要急着怀疑迁移失败先把 WSL 彻底关掉再检查一下注册表里是否还有旧路径的残留条目或者是否有其他发行版特别是 docker-desktop-data还在 C 盘。用 PowerShell 重新跑一遍第 1.1 节的查找 vhdx 命令看看 C 盘 Packages 目录下还有没有其他ext4.vhdx。另一个容易被忽略的步骤迁移后不要立刻删掉 D 盘的 tar 备份。我建议先在迁移后的 WSL 里正常用一两天跑几个项目确认数据完整、服务正常再把 tar 删掉或者把它转移到一个移动硬盘里长期保存。它就是你整个 Linux 环境的“系统镜像”留着没坏处。4.2 VHDX“只长不缩”的真相与压缩操作问一个很多人的共同困惑为什么我在 Linux 里删了几十个GB的文件Windows 的磁盘剩余空间一点都没变这其实不是 WSL 设计的缺陷而是虚拟磁盘的特性在作怪。ext4.vhdx是一个动态扩展的虚拟磁盘它在 Windows 侧显示的大小是“已经实际占用的物理文件大小”而不是文件系统内部所有块的总和。当你在 Linux 里删文件时ext4 文件系统会把这些块标记为空闲重新分配但不会主动告诉 Windows“这些块我可以还给磁盘”。所以 vhdx 的物理文件大小只增不减删文件只会让 Linux 内部多出可用空间不会让 Windows 侧多出可用空间。最简单的解决办法是开启稀疏文件支持前提是 WSL 版本足够新。新版 WSL0.67 及以上支持wsl --manage Ubuntu-22.04 --set-sparse true这个命令会把 vhdx 标记为稀疏文件之后删除文件时空间会自动归还给 Windows。如果你的版本支持建议迁移完顺手开一下。如果版本不支持或者开启稀疏后还是觉得空间占用太大可以手动压缩 vhdx。先wsl --shutdown然后以管理员身份打开 diskpartdiskpart在 diskpart 交互界面里依次执行select vdisk fileD:\WSL\Ubuntu-22.04\ext4.vhdx attach vdisk readonly compact vdisk detach vdisk exit整个过程和压缩 Hyper-V 虚拟磁盘的思路完全一样原理是让 vhdx 内部的空闲块以零填充后被物理文件收缩机制释放。压缩时间取决于磁盘大小和碎片程度几十GB的盘可能需要几分钟。压缩完回到 Windows重新打开 WSL一切如常。4.3 给迁移后的环境做空间规划迁移完成后最好在目标盘建立清晰的目录结构不要随手把 vhdx 扔在盘符根目录。我自己习惯这样做D:\WSL\ Ubuntu-22.04\ ext4.vhdx docker-desktop-data\ ext4.vhdx D:\wsl-backup\ ubuntu-22.04-2025-06-01.tar目录分两块一块放真实运行数据一块放备份 tar。每次大版本升级或者重要项目变更前导出一次 tar命名时带上日期。这样即使后续 D 盘也出问题你还留着可以从头恢复的种子。如果 D 盘本身空间也不宽裕建议用wsl --manage 发行版 --set-sparse true开启稀疏后再定期做一次压缩巡检。这个习惯能避免 WSL 的虚拟磁盘像气球一样越吹越大。5. 替代路线与更多方案直接装到新盘、目录迁移、第三方工具怎么选主线流程适合已经装好 WSL 的用户。但如果你的 WSL 还没装或者你在纠结要不要用工具辅助这里聊几条替代路线和它们各自的使用场景。5.1 新装系统的“一步到位”做法如果你还没安装 WSL或者准备在另一台电脑上从零搭建环境完全不用再走“先装 C 盘再迁移”的弯路。较新版本的 WSL 已经支持在安装时就指定安装目录类似这样wsl --install Ubuntu-22.04 --location D:\WSL\Ubuntu-22.04如果你的 WSL 版本支持--location参数安装过程会直接把这个发行版的数据目录放到 D 盘省去后续导出导入的折腾。实测下来不同版本对--location的兼容程度不完全一致建议先执行wsl --version确认版本如果不支持就按第二节的流程安装完再迁效果一模一样。还有一个点通过 Store 安装的发行版更新机制和通过wsl --import导入的发行版不一样。Store 版本可以随 Windows 更新一起更新而 import 进来的发行版本质上是“手动注册的 tar 恢复体”不会通过 Store 更新。如果你很在意这一点迁移后就需要自己定期执行发行版内部的系统更新比如sudo apt update sudo apt upgrade对日常使用没什么影响但知道这个机制免得日后疑惑“为什么我的 Ubuntu 没有收到应用商店更新”。5.2 目录联接方案mklink /J 的适用场景和风险还有一个网传方案是把ext4.vhdx剪切到 D 盘再在原来的 C 盘路径上用管理员权限执行mklink /J C:\Users\你\AppData\Local\Packages\Canonical...\LocalState D:\WSL\Ubuntu-22.04这样注册表里的路径不用改系统访问 C 盘原路径时会自动跳到 D 盘的真实目录。这个方案的优点是速度快、不用导出导入几十GB的 vhdx 几秒钟就能“搬家”。但我不太推荐这个方法作为长期方案原因是它太依赖 Windows 的目录联接稳定性了。一旦 Windows 大版本更新、WSL 包更新或系统还原都有可能把这个联接目录重置而且如果你不熟悉mklink /J和快捷方式的区别以后清理 C 盘时很容易误删。所以我的结论是这个方法适合应急比如 C 盘只剩几个GB、连导出空间都不够的紧急情况正常情况下多花半小时走 export/import 是更稳妥的选择。这里额外提一个操作技巧如果你迁移前 C 盘空间已经告急到连导出 tar 的位置都挤不出来可以在 D 盘先建好备份目录直接把 tar 导出到 D 盘。这样整个过程不依赖 C 盘剩余空间只是导出时源 vhdx 读取速度会受一些影响无伤大雅。5.3 第三方工具如 move-wsl、LxssManager 怎么选网上有一些专门做 WSL 迁移的小工具比如move-wsl原理无非两种要么帮你封装 export/import 流程要么帮你改注册表配合文件移动。用是能用但我个人对这类工具的态度是可以了解不必依赖。原因有三第一官方wsl --export/wsl --import已经覆盖了绝大多数迁移场景没必要为“少敲几条命令”引入一个可能有兼容性问题的第三方程序第二这类工具多数是个人维护对新版 WSL、新发行版的支持不一定及时万一在导出解析环节出了 bug你的数据就悬了第三排查故障时如果用官方命令出了问题社区里有大量现成的解决方案可以参考而第三方工具的报错往往只能去它的开源仓库里翻 issue。如果你真的想用工具可视化迁移我建议也先手动做一次 tar 导出备份把保命底线握在自己手里然后再用工具去尝试。数据安全永远优先于操作效率。6. 我踩过的坑和排查思路迁移失败时的完整复盘最后把我也遇到过并帮朋友处理过的几个高频问题拎出来按“问题表现 - 排查链路 - 解决方案”的方式复盘一遍。如果你想一次迁移成功这一章值得重点看。6.1 导出时报“文件名、目录名或卷标语法不正确”这个错误是新手最容易碰到的绝大多数时候不是你的 vhdx 坏了而是发行版名称输入有误。比如实际名称是Ubuntu-22.04你随手敲成了Ubuntu或者名字里带空格你没加引号PowerShell 把参数切成了两段。排查链路执行wsl -l -q让它只输出纯发行版名称避免显示里的*、默认这些干扰信息。把输出的名字原样复制到命令里不要手打。如果名称里确实有特殊字符用双引号把整个名称包起来。另外有一种情况某些从企业镜像或离线包安装的发行版名称中间可能带点、带下划线比如Ubuntu-20.04-Custom。这种名字最容易在复制时漏掉后半段建议先在记事本里粘好命令再执行。6.2 注销前没确认导出文件完整性等于直接删库我见过一位朋友的惨痛经历他执行wsl --export后看到控制台有条报错但因为报错夹杂在大量输出里没注意就直接接着跑wsl --unregister结果旧数据被删除导出的 tar 还是不完整的整个环境的项目文件全没了。最终只能从 Git 远程仓库拉代码、用手头备份慢慢重建。那怎么判断导出成功最简单的方法是看 tar 文件大小。一个正常的 WSL2 发行版不管里面实际用了多少空间导出的 tar 一般至少有几GB。如果导出来的文件只有几十MB大概率是不完整的。另外Linux 工程师常用的校验做法也很简单在 PowerShell 里计算哈希值Get-FileHash D:\wsl-backup\ubuntu-22.04.tar -Algorithm SHA256导出完成后记录下这个哈希值导入成功后可以重新计算一次两者一致基本可以确认文件传输完整。注意如果你只在同一台机器上导出又导入哈希值不会因为文件移动而改变所以比对是有效的。6.3 导入后启动报错 0x80070050、0x80370102、0x80070003这几个常见错误码对应的根因和解决思路差别很大。0x80070050通常表示“文件已存在”常见于导入目标目录里已经有一个旧的ext4.vhdx。比如你之前在 D 盘手动建了同名目录里面可能残留了历史文件。处理方式确认里面没有重要数据后把目录清空或者换一个新的目录导入。0x80370102一般是虚拟化功能异常。迁移这个动作本身不会触发它但如果你安装 WSL2 后操作系统更新过、或者 BIOS 里虚拟化设置被动过导入时新建虚拟机就有可能会失败。排查时先去“启用或关闭 Windows 功能”里确认“适用于 Linux 的 Windows 子系统”和“虚拟机平台”都勾选了再检查 BIOS 里 Intel VT-x / AMD SVM 是否开启。0x80070003多半是路径不存在或者没有权限。比如导入目标D:\WSL\Ubuntu-22.04没建目录或者这个目录在 OneDrive、网络驱动器这类特殊位置。WSL 的发行版数据一定要放在本地物理磁盘目录不要放到云同步目录或网络盘上否则虚拟机文件锁和同步服务会打架导致各种奇怪问题。6.4 迁移后 VS Code、资源管理器访问 \wsl$ 旧路径失效迁移完成后文件资源管理器地址栏里以前保存的\\wsl$\Ubuntu-22.04\home\用户这类路径可能会提示找不到网络路径。这是因为 WSL 发行版重新注册后实例 ID 已经变化旧的 WSL 网络共享句柄失效了。解决办法是删除资源管理器里旧的地址历史重新输入\\wsl.localhost\Ubuntu-22.04或者\\wsl$\Ubuntu-22.04。输入后回车WSL 会自动映射到新的实例。如果还是不行先执行wsl --shutdown等几秒再重新打开资源管理器访问。同样的逻辑也适用于 VS Code 的“Remote Explorer”。在 VS Code 左侧远程资源管理器里如果还残留旧的 WSL target直接刷新列表或者点击齿轮重新选择发行版即可。这个操作不影响你 Linux 里的任何文件只是客户端需要重新建立与 WSL 实例之间的通信通道。6.5 迁移后想回滚怎么安全退回 C 盘有朋友会问如果迁移完发现 D 盘性能不如 C 盘或者公司换机要求保持原样还能不能退回 C 盘当然可以而且你已经掌握方法了。回滚本质上就是把 export/import 流程反向跑一遍。假设你想让Ubuntu-22.04回到 C 盘默认位置先执行wsl --shutdown wsl --unregister Ubuntu-22.04然后重新创建一个 C 盘指定目录并导入New-Item -ItemType Directory -Path $env:LOCALAPPDATA\Packages\CustomUbuntuMigration wsl --import Ubuntu-22.04 $env:LOCALAPPDATA\Packages\CustomUbuntuMigration D:\wsl-backup\ubuntu-22.04.tar --version 2导入完成后别忘了再走一遍第 2.6 节的默认用户修复流程。回滚操作本身并没什么魔法本质上还是“导出备份 - 注销 - 导入新路径”这三板斧。经过这么多次 WSL 迁移和备份实践我现在已经养成了一个习惯每次给 WSL 里的项目做完重大环境变更就顺手导出一份 tar 到 D 盘备份目录。因为迁移这件事最妙的地方在于它逼着你完成了一次完整的“系统备份 恢复演练”——哪怕以后 C 盘、D 盘都出问题只要这份 tar 在换台电脑、重新装好 WSL一条导入命令就能把整个开发环境原地复活。从这个角度看迁移 WSL 不只是给 C 盘腾空间更是给你自己的数据多上了一道保险。