WSL2安装到D盘：--location参数把Ubuntu虚拟磁盘迁出C盘的完整指南

做开发这几年，WSL2已经成了我Windows机器上离不开的Linux运行环境。它比传统虚拟机轻量太多，又不依赖云服务器，直接在终端里敲wsl就能进入一个完整的Ubuntu环境，跑脚本、起服务、调Nginx、开Docker都跟在物理Linux上一样顺手。很多第一次接触的朋友以为它只是个“模拟器”，其实WSL2是微软在Hyper-V虚拟机平台之上做的轻量级内核方案，效果接近原生。

不过大多数人装完WSL2后都会遇到同一个麻烦：默认安装时，Ubuntu的虚拟磁盘ext4.vhdx被放到了C盘的用户目录下。这个文件会随着你apt install装包、拉镜像、编译项目、跑数据库而不断膨胀，C盘分分钟告急。我见过不止一个同事，周末清理C盘时发现这个文件占了四五十个G，删也不是不删也不是。

好在微软官方在较新的WSL版本里提供了--location参数，安装时可以直接把发行版装到指定目录，比如D盘。下面这些步骤我全部实测过，Windows 10和Windows 11都适用，从环境检查到一键装到D盘，再到存量系统迁移，一步步来就能搞定。

1. 项目核心：为什么要自定义安装目录到D盘

1.1 WSL2和Ubuntu解决什么问题

WSL2是Windows Subsystem for Linux的第二代实现。第一代是在Windows内核上做一层Linux系统调用翻译层，优点是启动快、文件IO直接访问Windows分区，缺点是很多依赖内核特性的软件跑不起来，像Docker、某些内核模块、高性能计算类工具都受限。第二代改成了真正的轻量级虚拟机，由Windows的Hyper-V虚拟机平台托管，运行一个实打实的Linux内核，系统调用可以全兼容，Docker、CUDA、systemd这些在传统虚拟机里能用的东西，在WSL2里也都能用。

对大多数开发者来说，WSL2解决的最大问题是“不用装虚拟机就能在Windows上写Linux代码”。以前要体验纯Linux环境，要么装VMware/VirtualBox开虚拟机，要么买一台云服务器，前者吃内存、启动慢，后者还得考虑网络和费用。WSL2启动一个发行版只要几秒钟，内存按需分配，命令行体验完全融合在Windows Terminal里，文件还能通过/mnt/c、/mnt/d直接访问Windows磁盘，开发效率高很多。

适合用WSL2的人群很明确：需要在Windows上跑Linux工具链的开发者、做Linux运维脚本测试的工程师、学习Linux命令和服务器配置的新手，以及用Docker Desktop做本地容器开发的Windows用户。微软在较新版本还支持了systemd，所以跑一些依赖systemd的服务也成了常规操作。

1.2 C盘里的ext4.vhdx是如何撑爆容量的

默认安装时，WSL2发行版的整个根文件系统会打包在一个名为ext4.vhdx的虚拟磁盘文件里。对Ubuntu来说，这个文件默认放在：

C:\Users\<你的用户名>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu...\LocalState\ext4.vhdx

如果你是直接从微软商店安装的，上面这个路径大概率就是你的文件所在位置。这个vhdx不是固定大小，而是一个动态扩展的虚拟磁盘，初始可能只有几GB，但只要你不断往里装东西，它就会持续增大，最大可以撑到256GB甚至更多。

注意这个文件不像普通文件夹那样可以随手剪切粘贴。因为它被WSL实例的注册表项和稀疏文件占用关系绑定，直接拖到D盘往往会导致WSL启动失败或文件损坏。这也是为什么--location参数这么关键——它从安装阶段就解决源头问题，而不是等C盘爆了再抢救。

C盘爆满的后果不只是“没空间”这么简单。Windows运行在满载C盘的环境下，分页文件、临时目录、软件更新都会变慢，严重时有些软件直接崩溃。我见过有人WSL里跑数据库，把几十GB数据写进了虚拟磁盘，结果C盘直接红了，Docker Desktop都起不来。所以我现在的原则是：新装WSL2一律放D盘，老系统也抽时间迁移过去。

1.3 --location参数：从源头解决目录迁移问题

在WSL的早期版本里，安装发行版时不支持指定安装路径。大家要么忍受C盘占用，要么用wsl --export和wsl --import这一套“导出-注销-导入”的土办法。这套方案能用，但流程长，而且容易踩默认用户变root的坑。好在现在WSL已经内置了--location参数，直接在新装发行版的时候指定目录，比老办法简单太多。

使用限制也顺便说清楚。--location参数只适用于“新安装”一个尚未存在的发行版，它的作用是告诉WSL：“把新发行版的ext4.vhdx放到我指定的目录下。”如果你系统中已经有Ubuntu了，再想给这个已存在的实例换目录，--location是不生效的，那部分场景还是得走 export/import。所以最好在安装之前就把目录规划好，省得后面白折腾。

从参数设计上也能看出微软的意图——把“安装发行版”和“磁盘规划”放在同一个步骤里，降低普通用户的迁移成本。后面第3节我会重点演示这个命令，配上参数细节和验证过程。

2. 安装前环境准备：先把地基打牢

2.1 检查Windows版本与CPU虚拟化

WSL2的前置要求是Windows 10版本2004（内部版本19041）以上，或者Windows 11。我在Windows 11 22H2和Windows 10 21H2上都跑过，功能完全正常。如果你的系统版本太老，官方给的路径是走Windows Update升级到最新版本，因为WSL2依赖的内核组件和Windows服务只在较新的系统里才完整。

另一个容易忽略的前置条件是CPU虚拟化。WSL2虽然是轻量级虚拟机，但底层跑Hyper-V虚拟机平台，需要CPU支持并开启VT-x（Intel）或SVM（AMD）。在BIOS/UEFI里一般叫“Intel Virtualization Technology”或“SVM Mode”，处于Disable状态时WSL2安装完成也无法启动，会报“请启用虚拟机平台”之类的错误。

怎么快速检查当前状态？管理员身份打开PowerShell，运行：

systeminfo

输出结果里会有一行“Hyper-V 要求”（不同系统版本文案略有差异），正常情况下可以看到虚拟化相关字段已经启用或提示“已在固件中启用虚拟化”。如果显示“虚拟化已启用: 否”，就去BIOS里打开这个开关。另外很多笔记本是“在Windows中能显示虚拟化状态”，但我还是习惯用systeminfo，干净利落。

2.2 启用WSL核心功能并升级内核

在新版Windows上，可以直接用管理员身份运行：

wsl --install

这个命令会顺手把“适用于Linux的Windows子系统”和“虚拟机平台”两个可选功能打开，并装最新WSL内核。不过我更推荐分两步走，因为可排查性更强：

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

两个功能启用后，重启系统，再用wsl --update把WSL内核升级到最新版。这一步很关键，因为--location参数是较新内核才支持的，如果你在旧内核上直接运行带--location的安装命令，很容易报“参数错误”或“无法识别选项”。

升级完成后，运行：

wsl --set-default-version 2

把默认版本固定为WSL2。某些机器同时装了WSL1和WSL2的发行版，这条设置会保证新装的发行版默认用WSL2架构，而不是退回WSL1。

提示：如果你的Windows版本较老，wsl --update可能无法在线更新，需要去微软官网手动下载WSL2内核更新安装包（MSI格式）。装完记得重启。

2.3 查看WSL版本状态

准备就绪后，先看一眼当前状态：

wsl --status wsl -l -v

wsl --status会告诉你默认版本和内核状态，wsl -l -v则列出所有已安装发行版及其WSL版本。如果之前用商店装过Ubuntu，这里会看到一行NAME是Ubuntu、VERSION是2的记录；如果提示没有发行版，说明是干净状态，正好可以直接从标题里的--location流程开始。

3. 实操核心：--location一键把Ubuntu装进D盘

3.1 创建目录与理解--location的本质

在动手前先规划目录。我习惯在D盘根目录建一个专门放WSL发行版的文件夹，例如：

D:\WSL\Ubuntu

不用提前创建也行，--location参数会自动创建目录，但我习惯手动建好，因为这样可以顺便确认D盘空间充足。命令执行时WSL会在该目录下生成一个ext4.vhdx文件，你的Ubuntu根目录、用户数据、安装的所有软件全部在这个文件里。

还有一个细节：--location指定的目录必须是NTFS格式的分区，文件系统不支持FAT32/exFAT存放虚拟磁盘，否则WSL启动会报错。Windows系统盘默认为NTFS，D盘是逻辑分区的话基本也是NTFS，但如果你D盘是从移动硬盘或U盘映射出来的，就要留个心眼。

3.2 完整安装命令与执行过程拆解

管理员身份打开PowerShell或Windows Terminal，运行：

wsl --install -d Ubuntu --location D:\WSL\Ubuntu

命令拆解一下：

• wsl --install是安装命令，不带-d时默认会尝试安装Ubuntu，带-d可以指定发行版；
• -d Ubuntu指定发行版为Ubuntu；
• --location D:\WSL\Ubuntu指定虚拟磁盘存放目录。

如果你希望实例名不叫“Ubuntu”，可以追加--name：

wsl --install -d Ubuntu --name DevUbuntu --location D:\WSL\Ubuntu

这样列出发行版时显示的是DevUbuntu，需要同时装多个Ubuntu版本时比较方便，但一般单实例用户用默认名就行。

按下回车后，WSL开始从微软服务器拉取Ubuntu安装包。这个过程需要一点时间，网速好可能一两分钟，网络波动时可能卡住，不要重复关闭窗口，耐心等。下载完成后会自动解压并把虚拟磁盘写入D:\WSL\Ubuntu\ext4.vhdx。

关键点来了：这个命令执行完成后，并不会立即让你设置Linux用户。你需要在新的终端里运行wsl或者wsl -d Ubuntu来首次启动。首次启动会提示“Installing, this may take a few minutes...”，然后让你输入新的UNIX用户名和密码。用户名建议全小写，不要带空格和特殊字符，密码输入时屏幕不会回显，属于正常现象。

注意：第一次启动时如果提示“参考的对象类型不支持尝试的操作”，多半是WSL内核没更新或虚拟化没开，回到第2节逐项排查。不要反复重启电脑，先检查wsl --status的输出。

3.3 安装完成后的验证

进入Ubuntu后，先跑几个命令确认一切正常：

cat /etc/os-release df -h / pwd

df -h /会显示根文件系统挂载点和已用空间，正常情况下挂载点是/，文件系统类型是ext4。从Windows侧检查D盘：

Get-ChildItem D:\WSL\Ubuntu

你应该能看到ext4.vhdx文件。随后运行：

wsl -l -v

输出里Ubuntu对应VERSION列显示2，就说明这个Ubuntu跑在WSL2架构上。此刻你的Ubuntu就已经完全脱离了C盘约束，后续所有系统盘压力都不会来自WSL了。

4. 存量迁移方案：已经装在C盘怎么办

4.1 为什么export/import是不可或缺的备胎

如果你的Ubuntu已经装好了，或者是从微软商店安装的默认位置，现在想迁移到D盘，官方并没有提供一种类似“原地移动目录”的命令，最稳妥的路径还是 export + unregister + import 三部曲。别嫌麻烦，这套方案能做到数据不丢。

为什么不能直接移动文件夹？前面提过，ext4.vhdx文件与WSL的注册表项、实例GUID绑定，直接改路径后WSL找不到原有实例，即使你改了注册表也很容易启动失败。而export生成的是一个tar格式的快照，包含了完整的文件系统、你安装的软件、用户数据，import时再指定新目录重建一个实例，从逻辑上讲是重新注册了一个环境。

考虑到是存量迁移，我建议在动手前先记录当前Ubuntu里有哪些重要数据、是否有未提交的Git分支、有没有正在跑的数据库服务，这些都是迁移前必须确认的。

4.2 完整迁移流程实录

第一步，关闭所有WSL实例，避免文件占用：

wsl --shutdown

第二步，导出当前Ubuntu到tar备份文件。先创建备份目录：

New-Item -ItemType Directory -Force -Path D:\wsl-backup wsl --export Ubuntu D:\wsl-backup\ubuntu-backup-20250115.tar

这里tar文件不要放在C盘，否则迁移完又给C盘增加压力。导出过程看虚拟磁盘大小，几十GB的导出可能需要几分钟，耐心等待。

第三步，注销原实例。这一步会删除C盘上的原注册记录和虚拟磁盘，但因为有tar备份，所以不慌：

wsl --unregister Ubuntu

注意：--unregister是删除操作，命令敲下去之前一定要确认tar文件完整存在。一旦注销，原C盘里的ext4.vhdx默认会被清理，无法找回。

第四步，从tar备份导入到D盘新目录：

wsl --import Ubuntu D:\WSL\Ubuntu D:\wsl-backup\ubuntu-backup-20250115.tar

导入完成后，D:\WSL\Ubuntu下会生成新的ext4.vhdx。此时再运行wsl -d Ubuntu，你会发现能正常进入，但用户可能变成了root，因为import重建的实例没有默认用户信息。这就是下一节要处理的问题。

4.3 迁移后的默认用户修复与验证

import后默认root登录是最常见的坑。修复方法是在Ubuntu里修改wsl.conf，指定默认用户。

在root登录状态下：

sudo vim /etc/wsl.conf

如果没有这个文件就新建，写入：

[user] default=你的用户名

保存后退出，回到Windows侧执行：

wsl --shutdown

然后重新进入：

wsl -d Ubuntu

此时应该已经切换到你原来的普通用户，并且home目录下的文件、软件、历史命令都还在。如果原来的默认用户名你忘了，可以从tar包里的home目录看到：/home/下的文件夹名就是用户名。

验证迁移结果：

wsl -l -v Get-ChildItem D:\WSL\Ubuntu

确认ext4.vhdx在D盘，同时C盘对应位置已经不再占用。整个迁移完成，C盘空间原地释放。

5. 初始化配置与中文使用环境

5.1 换源与系统更新

装好Ubuntu后第一件事不是装开发工具，而是换软件源。Ubuntu官方源在海外，国内网络环境下apt update慢到怀疑人生，装个gcc都能超时，所以这一步必须做。

我习惯把/etc/apt/sources.list换成清华源或阿里源。以Ubuntu 24.04为例，源文件里的地址格式是http://archive.ubuntu.com/ubuntu/，换成https://mirrors.tuna.tsinghua.edu.cn/ubuntu/或https://mirrors.aliyun.com/ubuntu/即可。

操作方式很简单，先备份原文件再编辑：

sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak sudo vim /etc/apt/sources.list

Ubuntu 24.04的新版本通常还引入了sources.list.d中的deb822格式，也可能在/etc/apt/sources.list.d/ubuntu.sources文件里。不同版本入口不同，你只需要把里面所有archive.ubuntu.com或security.ubuntu.com相关域名替换成镜像站对应域名即可，不需要纠结文件后缀。

换完后：

sudo apt update && sudo apt upgrade -y

更新到最新状态，顺手安装一些基础开发包：

sudo apt install -y build-essential vim git curl wget net-tools

build-essential里包含gcc、g++、make，之前热词里有“ubuntu安装gcc失败”，绝大多数情况下就是没装build-essential或者源有问题，这个包装完基本不会再遇到。

5.2 中文输入法配置

WSL2里的中文输入法是个容易被忽略的需求。如果你只是在Windows Terminal里跑命令行，终端本身不会直接弹出输入法框架，要输入中文可以直接切回Windows侧输入法。但如果你用WSLg跑Linux图形程序，或者需要在WSL里的编辑器输入中文，就需要在Ubuntu内装输入法框架。

我的做法是安装fcitx5：

sudo apt install -y fcitx5 fcitx5-chinese-addons

安装完成后，编辑~/.bashrc追加环境变量：

export XMODIFIERS="@im=fcitx" export GTK_IM_MODULE=fcitx export QT_IM_MODULE=fcitx

保存后执行source ~/.bashrc，然后启动输入法：

fcitx5 &

第一次启动后需要打开“配置”界面，添加拼音输入法。如果界面是英文，记住菜单路径是 Configure -> Input Method -> Add，勾选Pinyin即可。

这里的注意点：环境变量必须写在用户配置里，而不是系统全局/etc/environment，因为WSLg的X/Wayland会话是按用户启动的，写在全局可能不生效。另外如果你修改了~/.bashrc后终端闪退或者所有命令都不识别，别慌，下一节会讲怎么救回来。

5.3 开发环境整合：Docker Desktop与Nginx场景

WSL2和Docker Desktop是绝配。Docker Desktop默认支持WSL2后端，启用后Windows上的Docker命令和WSL内的Docker命令可以共享同一个引擎。要做的只是安装Docker Desktop后在Settings -> Resources -> WSL Integration里，勾选你对应的发行版（比如Ubuntu）即可。

我在日常开发中的典型场景是：在WSL2的Ubuntu里直接启动Nginx调试静态站点和反向代理，location匹配规则跟生产Linux完全一致，因为这就是一个真正的Linux内核环境。以前在Windows下用Nginx还要考虑路径分隔符、符号链接权限问题，现在一句sudo service nginx start就完事。如果你的工作流涉及Nginx的location规则调试，WSL2相比传统虚拟机的最大优势就是启动快、命令直接、还能用/mnt/d直接访问D盘代码目录。

同样的工作流还可以延伸到数据库、Redis、Consul这些中间件。所有服务的安装方式、配置文件路径、日志输出都跟云上生产环境保持高度一致，这是WSL2带来的最实在的价值。

6. 常见问题速查与避坑笔记

6.1 高频问题排查表

我整理了一张自己最常遇到的WSL2问题表，按症状、原因、解决方法三列来查。

这张表基本覆盖了90%的入门问题。下面挑几个我踩得比较深的坑展开讲。

6.2 我踩过的坑与最终解法

先说下载卡住。我最早在Windows 10上装WSL2时，下载Ubuntu卡了将近半小时，进度条一直停在“Installing”。后来发现是网络组件异常，我做了两件事：管理员身份运行PowerShell，执行netsh winsock reset重置Winsock目录；然后重启电脑，再执行wsl --unregister Ubuntu把半成品实例清掉重装。这两个步骤下来就正常了。

再说环境变量改坏的案例。有一次在~/.bashrc里写PATH变量时漏了引号，结果每次打开WSL都提示command not found，连sudo都用不了。这时在Windows侧用管理员终端执行：

wsl -u root

直接以root身份进入一个全新的shell，再编辑/home/用户名/.bashrc把错误行改回来。这个命令真是救命，遇到配置炸了别急着卸载，先wsl -u root进去修文件。

还有一次是迁移后Docker Desktop连不上WSL。原因是我用--import重建的Ubuntu实例名虽然没变，但Docker Desktop的WSL集成列表里还需要重新勾选一次。解决路径：Docker Desktop Settings -> Resources -> WSL Integration，把对应发行版勾上，重启Docker Desktop即可。

6.3 性能与维护建议

WSL2跑得爽，但也要维护。虚拟磁盘会随着使用增长，删除文件后空间并不会自动还给Windows。想瘦身，先关掉WSL：

wsl --shutdown

再用PowerShell里的Optimize-VHD对D:\WSL\Ubuntu\ext4.vhdx执行压缩。Windows 10/11专业版一般能直接用：

Optimize-VHD -Path D:\WSL\Ubuntu\ext4.vhdx -Mode Full

如果你的系统没有Hyper-V工具，也可以试试Disk Management里手动压缩，或者用配置精简方式减少不必要的包。这个操作能把vhdx文件明显缩小，我一般一个季度做一次，释放几个G是常事。

内存占用方面，默认WSL2会用到宿主可用内存的50%左右，如果你想限制，可以在用户目录新建.wslconfig：

[wsl2] memory=4GB processors=4

改完wsl --shutdown再启动就生效。GPU/CUDA方面，WSL2支持GPU直通，Windows侧装好NVIDIA驱动后，在WSL内直接nvidia-smi或安装CUDA Toolkit就能用，不需要在虚拟机里再装驱动。我做过简单的CUDA测试，深度学习环境放在WSL2里跑完全可行，吞吐量和物理Linux基本无差别。

我对WSL2安装自定义目录这件事最大的体会是：能在一开始解决的就别拖到后面。C盘空间这种问题，越早规划成本越低。如果你现在还没装，直接照着第3节的--location命令一步到位；如果已经装在C盘，也建议抽个不忙的时间把第4节的迁移流程走完，长痛不如短痛。

最后再分享一个小技巧：装完Ubuntu后我会第一时间把tar备份脚本写进计划任务，定期导出发行版状态，方便哪天系统重装时快速恢复。WSL2不是万能的，但配合Windows Terminal和Docker Desktop，它已经是我日常开发中最顺手的一套环境了。遇到问题别急着卸载，先把日志翻出来看，大部分坑都有明确解法。