WSL 安装与默认目录迁移：从 C 盘迁到数据盘的完整指南

1. 为什么我坚持把WSL从C盘挪走刚接触 WSL 的时候我图省事wsl --install一条命令敲下去Ubuntu 就装好了打开终端敲代码那叫一个爽。直到有次系统提示 C 盘空间不足我才顺着AppData\Local\Packages一层层翻进去发现那个ext4.vhdx虚拟磁盘文件已经涨到了四十多个 G。那一刻我才意识到WSL 默认把整个 Linux 根文件系统塞进了系统盘而且它会随着你用 Docker、装 CUDA、拉数据集、编译大型项目一路膨胀几十 G 只是起步。对一块 256G 的系统盘来说这就是悬在头顶的定时炸弹。这篇文章要解决的就是两件事一是在 Win10 和 Win11 上把 WSL 干净利落地装起来二是把它的默认安装目录从 C 盘迁到其他盘。前者涉及系统版本判断、虚拟化开关、功能启用和网络环境下的安装方式选择后者则是标题里最核心、也最容易翻车的部分——很多人以为装完再改目录是件小事结果迁移完发现默认用户变成了 root家目录里的配置全没了或者干脆把发行版搞废了重装。我会把这套流程拆到每一步的动机和坑点让你既能一次跑通也能在出问题时知道往哪查。适合阅读这篇内容的人很明确系统盘快满了的开发者、准备在 Windows 上长期跑 Linux 工具链的人、需要装 CUDA 或者binwalk这类重工具的人以及用 VS Code 连 WSL 写代码的日常用户。哪怕你是个刚知道 WSL 是什么的新手只要按着步骤走也能把环境搭好并且把数据落在你希望的盘上。下面我不讲虚的直接按“准备—安装—排障—迁移—验证—避坑”这条线走每一步都告诉你为什么这么做。1.1 WSL默认落盘的位置到底藏了什么WSL 的存储结构很多人其实没概念。当你通过商店或者wsl --install装一个发行版时微软并不是把它当成一个普通文件夹塞进某个目录而是打包成一个虚拟磁盘文件本质上是ext4文件系统封装在vhdx里。对于商店分发的发行版这个文件通常躲在C:\Users\你的用户名\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu22.04LTS_79rhkp1fndgsc\LocalState\ext4.vhdx注意这里有两层容易被忽略的东西。第一层是AppData属于用户目录很多人清理磁盘时不敢动但也不敢确认里面到底有多大第二层是那个带长串哈希的包名不同的发行版、不同的版本号这段字符串都不一样所以网上抄来的路径经常对不上号。这也是为什么“改默认目录”对有洁癖或者系统盘紧张的人来说不只是腾空间更是把不可控的位置变成自己能掌控的位置。这个vhdx还有个特性它只会涨不太会缩。你在 Linux 里rm掉一堆大文件宿主 Windows 看到的文件体积可能纹丝不动因为它内部是稀疏分配、按需增长的设计。所以你如果长期在 WSL 里做编译、拉模型、跑数据库这个文件会像滚雪球一样变大。提前把它放到一块空间充裕的数据盘上是比事后拿工具去压缩虚拟磁盘更省心的做法。1.2 迁移前先想清楚的三件事动手之前有三件事必须先确认否则后面的操作可能白做。第一件是目标盘的文件系统。WSL 的虚拟磁盘必须放在 NTFS 分区上如果你打算放到一块移动硬盘而它格式化成了 exFAT那是跑不起来的wsl --import阶段就会报错。第二件是空间余量导入的瞬间会同时存在“导出文件”和“新的虚拟磁盘”等于需要接近两倍的空间别把盘塞得只剩几个 G 才动手。第三件是备份意识迁移本质上是“导出—注销—导入”三连中间的注销步骤会删掉原有发行版万一导出文件损坏或者导入参数写错回滚的成本很高。我一般会建议先在目标盘建一个专门的目录比如D:\WSL然后把发行版和备份文件分开放比如D:\WSL\Ubuntu放实例D:\WSL\backup放导出的 tar。这样以后再加第二个发行版、或者需要定期备份的时候结构是清晰的。别小看这点目录规划等到你手上同时有 Ubuntu、Debian 和几个测试用的发行版时乱放的代价就是自己都记不清哪个 vhdx 对应哪个系统。还有一件容易被忽略的事迁移前把 WSL 里的重要工作提交或备份到 Git。虽然导出导入理论上保留全部数据但只要你用到了/etc/wsl.conf里的自定义配置、或者把用户切换过导入后这些不一定原样恢复。我遇到过最典型的场景就是导入完发现登录进去是 root之前配置的 SSH key、conda 环境路径全在别的用户目录下得手动切回来。2. Win10和Win11的准备动作不完全一样先说结论Win11 装 WSL 比 Win10 省事但不是所有 Win10 都能用那条“一条龙”命令。微软从 Windows 10 版本 2004内部版本 19041及更高版本开始才支持wsl --install这种一体化安装方式它会自动帮你启用所需功能、下载内核、设置默认版本为 WSL2。如果你的 Win10 是更早的版本比如 1809 或者长期服务版LTSC某些早期分支那wsl --install要么用不了要么行为不一致得走手动启用功能的老路。判断方法很简单打开 PowerShell敲winver看弹出的版本号。19041 及以上就属于“现代”版本可以走新流程低于这个数字就老老实实手动开功能。这一步别嫌烦很多网上教程之所以让人照着做却失败就是因为跳过了版本判断直接给命令结果读者的系统根本不支持。信息核对永远比盲目复制命令重要。2.1 虚拟化与系统功能的前置检查WSL2 底层用的是轻量级虚拟机所以你必须在 BIOS/UEFI 里开启 CPU 虚拟化。Intel 平台叫 VT-xAMD 平台叫 SVM名字不同但位置都在 CPU 配置一类的菜单里。怎么确认有没有开任务管理器切到“性能”标签看 CPU 那一栏右下角会有“虚拟化已启用/已禁用”的字样。如果显示已禁用那就得进 BIOS 打开否则后面启用VirtualMachinePlatform功能时会提示你需要虚拟化支持。功能层面WSL 依赖两个可选的 Windows 功能Microsoft-Windows-Subsystem-Linux和VirtualMachinePlatform。前者是 WSL 的主体后者是给 WSL2 提供虚拟机能力的。即使在支持wsl --install的系统上我也建议手动确认这两个功能的状态用管理员权限的 PowerShell 跑dism.exe /online /get-featureinfo /featurename:Microsoft-Windows-Subsystem-Linux dism.exe /online /get-featureinfo /featurename:VirtualMachinePlatform看输出的“状态”一栏。如果都是已启用就跳过如果未启用可以用wsl --install让它自动处理也可以手动启用后重启dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart这两条执行完必须重启一次机器功能才会真正生效。很多人启用了功能却忘了重启然后抱怨 WSL 装不上这是个高频低级错误。2.2 一条龙命令与手动安装的取舍wsl --install最大的好处是省事它把功能启用、内核下载、默认版本设置、发行版安装打包成一步。但它有两个前提系统版本够新以及网络能顺畅访问微软的分发地址。前者我们刚讲过后者是很多国内用户真正的痛点——命令敲下去卡在“正在安装”半天不动或者干脆报连接超时。我的经验是如果网络环境顺畅wsl --install直接用装完重启一次就能进系统如果网络不稳定别硬刚直接走“手动启用功能 手动下载发行版离线包”的路子反而更快更可控。手动流程的控制感更强你能清楚知道每一步在干什么出错也好定位。自动化命令适合“一次成功”的场景一旦卡住它给你的报错信息往往很模糊不如自己掌控每一步。这里要提醒一句wsl --install默认装的是 Ubuntu如果你想要特定版本比如 Ubuntu-22.04可以加-d参数指定。想知道有哪些可选的发行版用wsl --list --online。不过这条命令本身也可能因为网络问题超时这也是为什么我后面会专门讲离线包方案。3. wsl --install 卡住、403、连接超时的处理思路这一节专门讲安装阶段最让人抓狂的几类问题。热词里出现的“wsl --install 太慢”“已禁止(403)”“连接超时”“计算机无法连接到远程计算机”本质上都指向同一件事命令在访问微软的下载端点时没成功。理解这一点解决思路就清晰了——要么让网络路径变顺要么跳过在线下载改用离线包。先说 403 这类报错。它通常是请求被拒绝可能是临时的服务端问题也可能是你所在网络对某些域名做了限制。遇到这种情况第一反应不要是反复重试而是换成手动安装路线功能自己启用内核更新包和发行版包自己下载。这样完全不依赖那条命令的在线流程成功率反而更高。连接超时同理与其在命令行里干等不如把主动权拿回来。3.1 下载慢的根因在哪wsl --install在背后其实要做好几件事更新 WSL 内核组件、从分发渠道拉发行版包。这些资源不在国内的普通网络上都能稳定访问所以慢是常态。你可以先跑wsl --update单独更新内核如果它也很慢或者报错那说明在线途径就是走不通这时候纠结命令参数没有意义。我的做法是分而治之内核更新包是一个独立的安装文件wsl_update_x64.msi这类发行版也有独立的包或安装程序。把它们分开下载、分开安装哪一步慢就单独处理哪一步而不是让一条命令把所有环节绑在一起。这种“拆解问题”的思路在做运维排障时同样适用一个卡住的整体流程往往拆成小步就豁然开朗了。3.2 403与超时的绕行方案当在线安装反复失败时直接切到手动流程。步骤顺序是这样的先用第 2 节的dism命令启用两个功能并重启然后手动安装 WSL2 内核更新包接着设置默认版本为 2wsl --set-default-version 2最后安装发行版。发行版的获取方式有两种一种是通过商店另一种是下载官方提供的离线安装包。商店方式依赖网络和账户登录离线包方式则是一锤子买卖下载一次管很久。离线包通常是以.appx或.AppxBundle形式分发的。拿到之后如果直接双击装不上可以把后缀改成.zip解压然后运行里面的可执行文件安装。这个技巧用过一次就记住了它的原理是这些包本身就是压缩归档只是带了商店应用的封装。解压后运行安装程序它会自动往你的系统里注册这个发行版装完在开始菜单就能看到对应的入口。3.3 离线安装的完整操作路径我整理一下离线路线方便你照着走。第一步确认系统版本和虚拟化没问题功能已启用且重启过。第二步装好 WSL2 内核更新包wsl --set-default-version 2设置默认版本。第三步把下载好的发行版离线包改名解压运行安装程序等它提示安装完成。第四步启动发行版第一次会要求你创建一个 Linux 用户名和密码。这里有个细节离线包安装的发行版第一次启动时创建的用户就是它默认登录的用户这点和商店安装一致。所以如果你后面打算迁移目录记好这个用户名迁移后要用它恢复默认用户身份。另外如果第一次启动时报出“WSL 版本过旧”之类的提示说明内核组件没装好或者默认版本没设对回去检查第二步。4. 把默认安装目录改到其他盘的完整打法这才是全文的重头戏。改 WSL 安装目录分两种情况一种是还没装发行版直接指定安装位置另一种是已经装了需要把现有实例搬过去。前者对新版本的 WSL 来说相对简单后者则要用“导出—注销—导入”这套组合拳。我把两种都讲透你根据自己的状态选。需要先说明的是微软在较新的 WSL 版本里增加了--location或-l参数允许你在安装时直接指定目录比如wsl --install -d Ubuntu-22.04 --location D:\WSL\Ubuntu这个参数让你从源头就把发行版装到非系统盘省去后续迁移的麻烦。但它的可用性取决于你的 WSL 版本老版本识别不了这个参数会报错。所以稳妥起见我下面重点讲通用的迁移法因为它不挑版本任何已经装好的 WSL 都能用。4.1 新装直接指定路径的可行做法如果你的 WSL 版本支持--location那新装就简单了。先wsl --list --online确认可用的发行版名字然后用带--location的命令安装。这里要注意目录要提前建好或者确保父目录存在且落在 NTFS 分区上。装完之后用wsl --list --verbose看一下确认它确实在运行并且是版本 2。但这个方案有个现实限制--location参数在早期 WSL 版本里并不存在你要先wsl --update把组件更新到较新的版本才可能用到。而前面说过wsl --update本身在受限网络下可能失败这就形成一个循环困境。所以实际当中很多人的 WSL 版本并不够新直接指定路径的路走不通只能老老实实走迁移。这也是为什么我把迁移法当作主线来讲。提示无论哪种方式目标目录都不要放在会被同步盘、杀毒软件频繁扫描的路径下虚拟磁盘文件被反复读写扫描会影响性能甚至可能引起文件锁冲突。4.2 已装发行版的导出注销导入迁移法这是最通用、最值得掌握的一套流程。整个逻辑是把现有发行版完整导出成一个 tar 归档文件注销掉原实例再从 tar 文件导入到新目录。听起来简单但每一步的细节决定成败。动手前先关掉所有 WSL 会话避免文件被占用wsl --shutdown然后确认发行版名字注意名字大小写要和wsl --list --verbose里显示的完全一致wsl --list --verbose接着导出。假设发行版叫Ubuntu-22.04导出到 D 盘wsl --export Ubuntu-22.04 D:\WSL\backup\ubuntu2204.tar这个 tar 文件就是整个系统的快照包含你的全部文件、已装的软件、配置。导出过程视系统大小可能几分钟到十几分钟耐心等它完成不要中途打断。导出成功后建议先别急着注销去目标目录确认 tar 文件大小合理、能正常列出内容给自己留个后路。4.3 --import 参数细节与版本号的坑注销和导入是紧挨着的两步。注销会删除原实例所以务必在导出确认无误后再执行wsl --unregister Ubuntu-22.04然后从 tar 导入到新目录。--import的语法是wsl --import 新名字 安装位置 tar文件路径 [--version 2]wsl --import Ubuntu-22.04 D:\WSL\Ubuntu D:\WSL\backup\ubuntu2204.tar --version 2这里的坑有几个。第一名字可以改但改了之后所有引用这个名字的地方都要跟着改第二安装位置那个目录必须是空的或者不存在WSL 会在里面生成新的ext4.vhdx第三--version 2一定要带上否则可能导成 WSL1性能和兼容性都不是你想要的。带上这个参数导入的就是 WSL2 实例。导入完成后wsl -d Ubuntu-22.04进去看看。这时候你大概率会发现自己是 root不是原来的用户。别慌这是正常现象——导入时 WSL 不知道你原来的默认用户是谁直接给了 root。解决办法在下一节的配置文件里。4.4 恢复默认用户与目录结构说明要恢复原来的用户身份最通用、最稳的方法是修改/etc/wsl.conf。用 root 身份进入系统后编辑这个文件没有就创建sudo nano /etc/wsl.conf写入[user] default你的用户名保存退出然后回到 PowerShell 执行wsl --terminate Ubuntu-22.04让配置生效再重新进入就会发现已经是你熟悉的用户了。注意这里的用户名必须是系统里真实存在的如果记不清在 root 下用ls /home看一眼就知道。导入之后新目录里会出现一个ext4.vhdx这就是你的 Linux 根文件系统从 C 盘换到了 D 盘。你可以对比一下迁移前后 C 盘AppData\Local\Packages里对应发行版的目录通常会被清空或者不再有那个大文件。这一步做完空间问题算是彻底解决了。另外提醒一句迁移完 tar 备份别急着删留一段时间等确认新环境一切正常再清理给自己留个后悔药。5. 迁移之后必须做的几项验证迁移完成只是第一步能不能正常用、用得顺不顺还要做几项验证。我见过太多人迁移完就直接开跑项目结果莫名其妙报错最后发现是默认用户不对、或者发行版版本从 2 掉回了 1、或者存储配置没跟上。这几项花你十分钟能省掉后面几小时的排查。验证的核心是“身份、版本、存储、编辑器接入”四个维度。身份对了你的环境和权限才对版本对了性能才有保障存储配置合理WSL 才不会悄悄把你的内存吃光编辑器接得上日常开发才顺畅。按这个顺序过一遍基本不会有遗漏。5.1 默认发行版与用户状态确认先用wsl --list --verbose看全局状态。重点看三列名字、状态、版本。名字要和你导入时用的一致版本那列如果是 1说明导入时忘了带--version 2需要用wsl --set-version 名字 2转换转换过程会耗时系统越大越久默认发行版前面会有个星号如果你有多个发行版用wsl --set-default 名字把常用的设成默认。用户状态确认更简单直接wsl -d 名字进去敲whoami和echo $HOME。如果whoami返回 root说明/etc/wsl.conf没配好或者没生效$HOME若指向/root或者/home/用户名而目录不存在说明用户配置有问题。正常情况下whoami是你创建的用户$HOME是/home/你的用户名。这一步别偷懒它是后面所有操作的基础。5.2 .wslconfig 与内存磁盘配置WSL2 默认会占用宿主机的很大一部分内存和 CPU因为它底层是虚拟机。如果你机器内存不大跑几个重活就可能卡顿。可以创建C:\Users\用户名\.wslconfig来做全局限制[wsl2] memory8GB processors4 swap2GB这是配置在宿主 Windows 上的不是配置在 Linux 里别搞混。改完文件执行wsl --shutdown让配置重载。注意这个文件路径在用户目录下和你在别的盘上装发行版并不冲突它管的是 WSL2 整体资源上限和发行版放哪个盘无关。很多人到处找“迁移后内存配置怎么写”其实位置没变还是用户目录下。磁盘方面迁移后你的 vhdx 在 D 盘了但它的增长和压缩机制没变。如果你将来想瘦身可以在wsl --shutdown后用wsl --manage 名字 --set-sparse true之类的方式处理稀疏文件取决于版本支持更通用的办法是先在 Linux 里清理无用文件再借助磁盘工具压缩虚拟磁盘。这一块视版本而定不确定就别乱试先把清理做好。5.3 在 VS Code 里接上迁移后的发行版用 VS Code 连 WSL 写代码是很常见的用法迁移后需要确认它仍然指向正确的发行版。打开 VS Code装好 WSL 扩展左下角会有个绿色的连接入口点它选择“连接到 WSL”它会列出你当前所有的发行版。选迁移后那个名字它会打开一个新窗口把服务端组件装到你的 Linux 里。如果列表里还显示着已经被注销的旧名字重启一下 VS Code 或者跑wsl --shutdown再开通常就刷新了。连上之后终端里pwd会在你的家目录说明身份和环境都对。这时候你之前装的工具链、Python 环境、Node 等如果是在 Linux 里全局装的应该都还在如果是装在旧用户目录下的确认家目录恢复正确后也都在。这一步跑通迁移就算真正完成了。6. 迁移路上最容易踩的几个坑讲完流程我把这些年踩过和见过的高频坑集中说一说。这些坑不是理论推演都是真实翻过车的地方踩过一次就记住了。如果你正准备迁移建议把这节先读一遍再动手。第一个高频问题是“注销了却没导出成功”。导出命令报错但没注意然后直接注销原实例就没了数据全失。规避方法很简单导出后先确认 tar 文件大小正常能列目录最好再执行注销。这一步多花的几十秒能救命。第二个高频问题是“导入后忘记恢复默认用户”导致以 root 身份乱改文件权限全乱。6.1 迁移后默认用户变root的处理这个问题出现频率太高单独拎出来说。现象是迁移后进系统提示符变成了root机器名cd ~进的是/root之前装在家目录的工具都找不到了于是有人以为数据丢了。其实数据在/home/原用户名里好好的只是默认登录身份变成了 root。处理方式就是第 4.4 节说的/etc/wsl.conf配置加上[user] default用户名然后 terminate 再进。如果配了还不生效检查两点一是文件路径和大小写是否写对Linux 区分大小写二是wsl.conf是不是放在了系统根目录下的/etc/里而不是用户家目录。某些发行版对配置格式也挑剔缩进和节名要写标准。实在不行用发行版自带的用户配置命令比如某些 Ubuntu 版本可以用ubuntu2204.exe config --default-user 用户名来设置路径在C:\Program Files\WindowsApps下找对应可执行文件这个方式更底层但也更麻烦优先用wsl.conf。6.2 跨盘访问与性能的真实差别有人担心把 WSL 放到 D 盘后性能变差这个担心有必要澄清。WSL2 的运行跟它在哪个盘上关系不大因为它是通过虚拟化运行的磁盘位置主要影响的是虚拟磁盘文件的读写。只要目标盘是健康的 NTFS 固态盘日常使用几乎感觉不到差别。真正影响性能的是“跨文件系统访问”也就是你在 Linux 里访问/mnt/c、/mnt/d这些 Windows 盘的位置这种跨系统读写才是慢的来源和 WSL 自身装在哪无关。所以如果你的项目代码同时要给 Windows 和 Linux 用建议把代码放在 Linux 文件系统里也就是 WSL 内部用 VS Code 连进去编辑而不是把代码放 Windows 盘再从 WSL 去访问。这一点在迁移后尤其值得注意因为很多人把 WSL 迁到 D 盘后顺手就把项目也放 D 盘然后在 Linux 里跨盘访问结果抱怨编译慢。分清楚“WSL 装在哪个盘”和“代码放哪个文件系统”是两位不同的问题。6.3 卸载、备份与后续扩容最后说后续管理。如果你要彻底卸载一个发行版用wsl --unregister 名字它会连同虚拟磁盘一起删掉这一步不可逆删前务必导出备份。备份用wsl --export定期做一次尤其是环境配置复杂、装了 CUDA 和各种工具链之后重装一次的成本很高一个 tar 就是最省事的还原点。扩容方面WSL2 的虚拟磁盘默认会随需要增长一般不用手动扩它自己能长到很大。你要管的是它的上限和实际占用配合.wslconfig控制内存、定期清理无用文件就够日常使用了。如果你一开始给目标盘留的空间就不大等到 vhdx 涨满会触发写入失败所以迁移前评估空间时按你预期用量的两三倍来预留比较稳妥。我个人在实际操作中的体会是把 WSL 迁到数据盘这件事一次做好胜过反复折腾。与其等到 C 盘飘红再手忙脚乱地搬不如在装的时候就规划好位置或者装完没多久就迁走那时候 tar 文件还小迁移快风险也低。等你装了几个月、几十 G 工具链再迁那才叫真正的体力活。