1. 为什么 WSL 的安装位置值得你花时间折腾很多人第一次装 WSL 的时候都是打开微软商店搜 Ubuntu点安装然后就开始用了。整个过程顺滑得让人根本不会去想一个问题这东西到底装在哪了直到某天 C 盘飘红打开存储感知一看一个叫ext4.vhdx的文件吃掉了四五十个 G才意识到问题的严重性。WSL 默认把整个 Linux 发行版的根文件系统打包成一个虚拟磁盘文件放在%LOCALAPPDATA%\Packages\下面那一串带随机字符的目录里。这个路径又深又隐蔽而且和系统盘绑死。对于用着 256G 或者 512G 系统盘的人来说这基本上就是个定时炸弹——你装个 CUDA、拉几个 Docker 镜像、跑几个 Python 虚拟环境盘就满了。所以这篇内容要解决的核心问题就一个把 WSL 从默认的 C 盘位置完整迁移到你指定的自定义路径比如 D 盘或者外接 SSD。迁移完之后原来的使用习惯完全不变终端里敲wsl照样进VS Code 照样连Docker Desktop 照样跑但磁盘空间压力彻底转移到别的盘上。适合看这篇内容的人包括C 盘空间告急的开发者、想把开发环境和系统盘分离的运维、需要在多块硬盘之间做环境规划的人以及那些准备换大容量 SSD 但不想重装整个 WSL 环境的人。下面我会从原理讲到实操把每一步为什么这么做都说清楚。2. 先搞清楚 WSL 到底把文件放在了哪里2.1 默认安装路径的构成逻辑WSL 的存储结构其实不复杂但微软把它藏得比较深。当你通过商店或者命令行安装一个发行版时系统会在下面这个位置创建一个包目录C:\Users\你的用户名\AppData\Local\Packages\在这个目录下每个 WSL 发行版都有一个独立的文件夹命名规则大致是CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc这种形式。进到这个文件夹之后再往下走LocalState你就能看到一个名为ext4.vhdx的文件。这个文件就是整个 Linux 系统的全部内容——根目录、home 目录、你装的所有软件、写的所有代码全在里面。注意不同发行版的包名不一样Ubuntu 是 Canonical 开头的Debian 是 TheDebianProject 开头的Kali 又是另一个。不要死记硬背用命令查最准。2.2 用命令精确定位当前安装位置与其在资源管理器里一层层翻不如直接用命令查。打开 PowerShell 或者 CMD执行wsl --list --verbose这个命令会列出你当前安装的所有发行版以及它们的状态。但要注意这个输出里并不直接显示路径。要拿到精确路径有两个办法。第一个办法是进注册表看。WSL 在注册表里登记了每个发行版的BasePathreg query HKCU\Software\Microsoft\Windows\CurrentVersion\Lxss /s /v BasePath输出里你会看到类似这样的内容BasePath REG_SZ C:\Users\YourName\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState第二个办法更直接在 WSL 里面执行explorer.exe .这会直接用资源管理器打开当前 Linux 目录对应的 Windows 路径。不过这个方法打开的是当前工作目录不一定能直接看到 vhdx 文件本身。2.3 为什么默认放在 C 盘是个问题C 盘作为系统盘本身就要承载 Windows 系统、各种软件、页面文件、休眠文件等等。WSL 的 vhdx 文件有个特点它只增不减。你删了 Linux 里面的文件vhdx 文件本身不会自动缩小。这意味着你哪怕只是临时编译了一个大项目然后删掉那部分空间依然被 vhdx 占着。再加上现在搞 AI 开发的WSL 里装个 CUDA 就是十几个 G再拉几个 PyTorch 的镜像又是十几个 GC 盘很快就撑不住了。而且 C 盘满了之后Windows 本身会变得极其卡顿各种临时文件写不进去整个系统都会受影响。把 WSL 迁到别的盘本质上就是把一个持续增长的大文件从系统盘挪走让系统盘保持在一个健康的剩余空间水平。这是最直接的收益。3. 迁移前的准备工作与方案选型3.1 迁移的两种主流方案对比目前把 WSL 迁到自定义路径主要有两种做法各有适用场景。方案操作方式优点缺点适用场景导出再导入wsl --export导出 tar 包注销后wsl --import导入到新路径官方支持兼容性好可跨机器迁移需要额外磁盘空间存放 tar 包耗时较长大多数场景首选直接移动 vhdx关闭 WSL 后直接剪切 vhdx 文件再修改注册表 BasePath速度快不需要额外空间注册表操作有风险路径不对会导致启动失败对注册表熟悉的老手我个人的建议是除非你对注册表操作非常熟练否则一律走导出导入的方案。这个方案是微软官方文档里明确支持的出问题的概率最低而且导出出来的 tar 包还可以作为备份保留。3.2 迁移前必须确认的几件事在动手之前有几项检查必须做否则中途出问题会很麻烦。第一确认目标盘有足够的空间。你可以在 WSL 里执行df -h /看一下根分区用了多少然后确保目标盘至少有这个数字两倍以上的剩余空间——因为导出过程中 tar 包和原始 vhdx 会同时存在。第二确认 WSL 版本。执行wsl --version确保你的 WSL 是较新的版本。老版本的 WSL 1 和 WSL 2 在迁移方式上有区别WSL 2 用的是 vhdxWSL 1 用的是目录结构处理方式完全不同。现在绝大多数人用的都是 WSL 2下面讲的操作也以 WSL 2 为准。第三记下当前默认登录的用户名。导出再导入之后默认用户会变成 root需要手动改回来。你可以在 WSL 里执行whoami记下当前用户名。第四把所有正在运行的 WSL 实例关掉。这个很关键如果 vhdx 文件正在被占用导出会失败或者导出不完整。wsl --shutdown执行完这个命令后等几秒钟确保所有 WSL 相关的进程都退出了。你可以打开任务管理器看看有没有vmmem或者wsl相关的进程还在跑。3.3 目标路径的规划建议目标路径不要选得太随意。几个原则不要放在中文路径下虽然现在 Windows 对中文路径支持好了很多但 WSL 相关工具链里有些组件对非 ASCII 路径处理仍然有问题。不要放在网络驱动器或者移动硬盘上除非你确定这个盘一直插着。WSL 启动时如果找不到 vhdx 文件会直接报错。建议单独建一个目录比如D:\WSL\Ubuntu或者E:\DevEnv\WSL把不同发行版分开放以后管理起来清晰。如果目标盘是 SSD那最好不过。WSL 的磁盘 IO 性能直接取决于 vhdx 所在物理磁盘的速度放在机械硬盘上会明显感觉到卡顿。4. 完整迁移实操从导出到导入的每一步4.1 第一步导出当前发行版为 tar 包假设你要迁移的发行版名字叫Ubuntu先确认一下wsl --list --verbose输出里会显示类似NAME STATE VERSION * Ubuntu Running 2记下这个名字然后执行导出。导出的目标路径建议放在目标盘上这样后面导入的时候不用再跨盘拷贝wsl --export Ubuntu D:\WSL\ubuntu-backup.tar这个命令执行的时候终端会卡住一段时间没有任何进度提示。这是正常的不要以为死机了。导出时间取决于你的 WSL 里有多少数据几十个 G 的话可能要等几分钟到十几分钟。实操心得如果你 WSL 里的数据特别大比如超过 100G建议先用wsl --shutdown彻底关闭然后用Optimize-VHD或者磁盘清理工具压缩一下 vhdx 再导出。不过Optimize-VHD需要 Hyper-V 模块家庭版 Windows 可能没有那就跳过这步。导出完成后去目标路径确认一下 tar 包的大小。如果只有几 KB 或者明显偏小说明导出失败了检查一下是不是有进程还在占用 vhdx。4.2 第二步注销原来的发行版确认 tar 包没问题之后就可以把原来的发行版注销掉了。这一步会删除原来的 vhdx 文件释放 C 盘空间。wsl --unregister Ubuntu执行完这个命令原来的发行版就从 WSL 的列表里消失了。你可以再执行一次wsl --list --verbose确认。注意这一步是不可逆的。虽然我们有 tar 包备份但如果你 tar 包有问题那就真的丢了。所以务必确认 tar 包完整之后再执行 unregister。我一般会先把 tar 包复制一份到另一个位置确认导入成功后再删掉备份。4.3 第三步导入到自定义路径现在把 tar 包导入到新的位置。先创建好目标目录mkdir D:\WSL\Ubuntu然后执行导入wsl --import Ubuntu D:\WSL\Ubuntu D:\WSL\ubuntu-backup.tar这个命令的三个参数分别是发行版名称、安装目录、tar 包路径。执行完之后WSL 会在D:\WSL\Ubuntu下面生成一个新的ext4.vhdx文件。导入完成后用wsl --list --verbose确认一下应该能看到 Ubuntu 已经在列表里了。4.4 第四步恢复默认登录用户导入之后有一个很常见的问题默认登录用户变成了 root。这是因为导入的时候没有指定用户WSL 默认用 root 登录。要改回原来的用户需要修改 WSL 的配置。对于较新版本的 WSL可以直接在 PowerShell 里执行ubuntu config --default-user 你的用户名注意这里的ubuntu是命令名不同发行版可能不一样比如 Debian 就是debian config --default-user。如果你不确定命令名可以在 WSL 里执行ls /usr/bin/ | grep config找一下。如果这个命令不存在那就手动改配置文件。在 WSL 里编辑/etc/wsl.confsudo nano /etc/wsl.conf添加以下内容[user] default你的用户名保存后退出然后在 PowerShell 里执行wsl --shutdown重启 WSL再进去就是你的用户了。4.5 第五步验证迁移结果迁移完成之后做几项验证第一确认当前路径。在 WSL 里执行df -h /看看根分区的大小是否正常。第二确认原来的文件都在。去你的 home 目录看看之前写的代码、装的软件、配置的环境变量应该都还在。第三确认网络和端口转发正常。如果你之前在 WSL 里跑了服务比如 Docker 容器或者开发服务器确认一下端口映射是否还工作。第四确认 VS Code 能正常连接。打开 VS Code用 Remote-WSL 插件连接看看能不能正常打开项目。第五确认 Docker Desktop 正常。如果你用 Docker Desktop 配合 WSL 后端打开 Docker Desktop 看看能不能正常启动容器。这几项都过了迁移就算彻底完成了。原来的 tar 包可以保留作为备份也可以删掉释放空间。5. 迁移过程中最容易踩的坑与排查方法5.1 导出时报错“系统找不到指定的文件”这个错误通常是因为发行版名称写错了。WSL 的发行版名称是区分大小写的而且必须和wsl --list输出里的完全一致。如果你不确定直接复制输出里的名字。还有一种可能是 WSL 没有完全关闭。执行wsl --shutdown之后等几秒再执行一次wsl --list --verbose确认所有发行版的状态都是 Stopped。5.2 导入后启动报错“参考的对象类型不支持尝试的操作”这个错误在较老版本的 Windows 上比较常见通常和 WSL 的版本有关。解决办法是更新 WSL 到最新版本wsl --update如果更新之后还是不行检查一下 Windows 的 Hyper-V 和虚拟机平台功能是否开启。在“启用或关闭 Windows 功能”里确认“虚拟机平台”和“适用于 Linux 的 Windows 子系统”都勾选了。5.3 迁移后默认用户不对每次都要 su这就是前面说的默认用户问题。除了用config --default-user命令还有一种情况是/etc/wsl.conf文件不存在或者配置没生效。确认一下文件路径和格式然后一定要执行wsl --shutdown完全重启配置才会生效。5.4 迁移后磁盘空间没有释放如果你迁移完之后发现 C 盘空间没有明显变化可能是原来的 vhdx 文件还在。检查一下%LOCALAPPDATA%\Packages\下面那个目录是否还在。正常情况下wsl --unregister会删除整个包目录但有时候会残留。手动删掉即可。另外Windows 的存储感知或者磁盘清理可能没有及时更新重启一下资源管理器或者等几分钟再看。5.5 Docker Desktop 无法启动Docker Desktop 和 WSL 的集成比较紧密迁移之后可能需要重新配置。打开 Docker Desktop 的设置找到 Resources 里的 WSL Integration确认你的发行版还是勾选状态。如果不行取消勾选再重新勾选一次然后重启 Docker Desktop。5.6 常见问题速查表问题现象可能原因解决方法导出命令卡住不动正常现象数据量大时耗时较长耐心等待不要中断导入后无法启动WSL 版本过旧执行wsl --update默认用户变成 root导入时未指定用户用config --default-user或改/etc/wsl.confC 盘空间未释放原包目录残留手动删除%LOCALAPPDATA%\Packages\下对应目录VS Code 无法连接WSL 服务未重启执行wsl --shutdown后重试Docker 容器启动失败WSL 集成配置丢失在 Docker Desktop 设置里重新勾选6. 迁移后的环境恢复与长期维护建议6.1 检查关键开发环境是否完好迁移完成之后不要急着开始干活先花几分钟把关键环境过一遍。如果你在 WSL 里装了 CUDA执行nvcc --version确认一下。如果你用 conda 或者 venv 管理 Python 环境激活几个常用的环境看看能不能正常导入包。如果你用 Docker跑一个docker run hello-world确认容器能正常启动。这些检查看起来琐碎但能帮你提前发现问题。我遇到过迁移之后 CUDA 驱动路径变了导致 PyTorch 找不到 GPU 的情况虽然不常见但检查一下总比写到一半发现跑不了强。6.2 把新路径纳入备份策略迁移到自定义路径之后你的 WSL 环境就不再和系统盘绑定了。这其实是件好事——你可以更方便地做备份。比如定期把 vhdx 文件复制一份到另一个盘或者用wsl --export定期导出 tar 包。如果你用的是 SSD 并且支持快照功能那就更省事了。不过大多数消费级 SSD 没有这个功能手动备份还是最靠谱的。6.3 后续安装新发行版时直接指定路径迁移过一次之后以后装新的 WSL 发行版就可以直接指定路径了不用再走一遍迁移流程。比如从商店装完 Ubuntu 之后直接用wsl --export和wsl --import把它挪到你想要的位置。或者更直接一点用wsl --import从离线包安装一步到位指定路径。对于需要离线安装的场景比如内网环境或者网络不稳定的情况可以先用wsl --export从一台机器导出 tar 包然后拷贝到目标机器上用wsl --import导入。这个流程和迁移是完全一样的只是多了一步拷贝。6.4 关于 vhdx 文件膨胀的长期对策前面提到过vhdx 文件只增不减。迁移到新盘之后虽然短期内空间压力小了但长期来看还是会膨胀。几个应对办法第一定期在 WSL 里清理不需要的文件比如apt clean、删除旧的日志、清理 pip 和 npm 缓存。第二如果 vhdx 膨胀得厉害可以用wsl --export导出再wsl --import导入一次这样会生成一个新的、紧凑的 vhdx。这相当于做了一次压缩。第三Windows 11 较新版本支持wsl --manage 发行版 --set-sparse true可以把 vhdx 设置为稀疏文件删除文件后空间会自动释放。这个功能非常实用建议开启。wsl --manage Ubuntu --set-sparse true开启之后你在 WSL 里删除文件Windows 这边看到的 vhdx 文件大小也会相应减小。不过要注意稀疏文件在某些文件系统上可能不支持比如 exFAT 格式的盘就不行。NTFS 没问题。6.5 多发行版共存时的路径管理如果你同时用多个 WSL 发行版比如一个 Ubuntu 做日常开发一个 Kali 做安全测试建议在目标盘上给每个发行版建独立目录D:\WSL\ ├── Ubuntu\ │ └── ext4.vhdx ├── Kali\ │ └── ext4.vhdx └── Debian\ └── ext4.vhdx这样管理起来清晰备份的时候也可以按目录单独备份。而且如果某个发行版出问题了直接删掉对应目录重新导入就行不影响其他的。7. 关于迁移这件事的一些个人体会我前前后后迁移过五六次 WSL 环境从最早的 WSL 1 到现在的 WSL 2从 C 盘到 D 盘再到外接 SSD各种情况都遇到过。最大的体会是迁移本身不难难的是迁移之前的规划和迁移之后的验证。规划阶段最重要的是想清楚目标路径放哪、空间够不够、以后会不会再迁。我见过有人迁到移动硬盘上结果拔了硬盘 WSL 就起不来了又得重新折腾。验证阶段最重要的是别偷懒该检查的都检查一遍尤其是默认用户和 Docker 集成这两块出问题的概率最高。还有一个很实用的技巧如果你不确定迁移流程是否顺利可以先拿一个不重要的发行版练手。比如装一个干净的 Ubuntu随便放点文件然后走一遍完整的导出导入流程。确认没问题了再迁移你主力开发环境。这样即使出问题损失也最小。最后说一个很多人忽略的点迁移完成之后记得把 Windows 的快速启动关掉。快速启动有时候会导致 WSL 的 vhdx 文件被锁定下次启动 WSL 时报错。在控制面板的电源选项里找到“选择电源按钮的功能”然后取消勾选“启用快速启动”。这个设置对 WSL 的稳定性有实实在在的影响尤其是你经常开关机的话。