这几年在Windows上做开发，我身边越来越多同事把WSL当成了默认的Linux环境。不夸张地说，装了WSL之后，我几乎不再需要开虚拟机，日常的shell操作、服务部署、数据处理脚本，全都在WSL里跑。这篇文章就围绕WSL的安装和迁移展开，从最基础的原理讲到真正的坑，包括wsl --install太慢怎么办、C盘空间被WSL吃光怎么搬家、VSCode里怎么连WSL写代码、Docker Desktop报WSL错误怎么排查。准备把从零到能用、再到用得顺手的一条完整路径，连同我踩过的坑和现在的习惯性操作，全部整理出来。无论你是第一次接触WSL的纯新手，还是已经在用但被磁盘占用和跨盘迁移折磨过的老手，这篇都能直接拿去参考。
1. 装之前先搞清楚：WSL是什么，该不该装
1.1 WSL 1和WSL 2到底差在哪
WSL的全称是Windows Subsystem for Linux，简单说，它让Windows可以在不装完整虚拟机的情况下直接运行Linux发行版。现在主流用的都是WSL 2，它跟第一代的实现方式完全不同。
WSL 1走的是系统调用转译路线，把Linux程序发出的系统调用翻译成Windows系统调用。好处是启动极快、内存占用小、不需要虚拟化支持，坏处是兼容性不够好，很多依赖内核特性的软件跑不了，文件操作性能也慢得让人抓狂。WSL 2则改成了轻量级虚拟机方案，用一个真正的Linux内核跑在上面，兼容性大幅提升，Docker、数据库、深度学习框架这些重型工具都能跑。代价是它会占用更多内存，虚拟磁盘文件也会随着使用慢慢变大。
我自己的对比感受是这样的：如果你只是想要一个能敲Linux命令的终端，WSL 1勉强够用；但如果你要跑Docker、装数据库、编译代码、做深度学习，就直接上WSL 2，别犹豫。微软也默认把WSL 2作为新版本的标准，所以这篇内容默认都基于WSL 2展开。
1.2 哪些人不建议用WSL
WSL虽好，但不是万能。我见过不少同学装了WSL之后发现不是自己想要的，所以先把“不适合的场景”说清楚。
第一，如果你需要跑带图形界面的完整Linux桌面环境，比如专门的Qt应用、带复杂GUI的设计软件，WSL虽然支持WSLg（Windows下的Linux GUI），但体验离原生Linux桌面还是有差距。这时候更推荐VirtualBox、VMware或者干脆双系统。
第二，如果你要做USB设备直通、串口调试、摄像头采集这类重度硬件访问，WSL 2在这块支持得比较有限。尽管最新版本对USB设备（usbipd）有支持，但配置复杂、稳定性一般，不如虚拟机来得干脆。
第三，如果你需要长时间运行依赖systemd的服务，虽然新版WSL已经支持systemd，但默认不开启，配置起来也比原生Linux多一层工作。需要长期稳定运行的服务器，还是交给真正的Linux机器或者云服务器更合适。
所以你看，WSL的定位更像是“开发者的日常主环境”，而不是“替代所有Linux方案”。装之前先问自己：我要不要在Windows里写Linux代码、跑Linux服务？如果是，WSL就是目前最轻量、最顺手的方案。
1.3 前置条件检查
在动手指令之前，先把电脑条件确认好，能省下后面一大半的折腾时间。
第一，Windows版本。WSL 2需要Windows 10 2004及以上版本，Windows 11就不用说了。老版本系统强烈建议先升级，否则会遇到一堆“功能无法开启”的报错。
第二，虚拟化功能。WSL 2依赖虚拟化和虚拟机平台，你得去BIOS/UEFI里确认CPU虚拟化已经开启。大部分主流电脑默认是开着的，但有些品牌机出厂默认关闭，特别容易踩坑。可以在Windows搜索栏输入“任务管理器”，切到“性能”标签页，最下面能看到“虚拟化：已启用”。如果是“已禁用”，就得重启进BIOS找Intel Virtualization Technology（Intel VT-x）或AMD SVM，把它打开。
第三，Windows功能。WSL本身依赖几个系统组件，最省事的方法是用管理员身份的PowerShell或者命令提示符，直接跑以下命令：
wsl --install这个命令会自动把“适用于Linux的Windows子系统”和“虚拟机平台”两个功能打开，然后下载安装默认的Ubuntu发行版。如果系统比较老，无法使用这一条命令，就得手动去“控制面板 → 程序 → 启用或关闭Windows功能”，勾选“适用于Linux的Windows子系统”和“虚拟机平台”，重启后再装。
2. 安装的两种路线：一条快捷，一条稳
2.1 标准安装流程：wsl --install一步到位
如果你的网络环境不错，最简单的安装方法就是先在管理员PowerShell里更新WSL并安装默认发行版：
wsl --update wsl --install等命令跑完后，按提示重启电脑。重启完，系统会自动弹出Ubuntu的初始化窗口，让你设置Linux用户名和密码，设置完就可以用了。
很多人在这一步会卡住，因为wsl --install的速度取决于网络到微软服务器的质量，部分网络环境下，下载发行版镜像慢到怀疑人生。遇到这种情况不要慌，可以先执行wsl --install --no-distribution，这一步只是把WSL本体和虚拟机平台装好，不含发行版，速度通常快很多。之后我再单独离线安装Ubuntu。
如果想装指定版本的发行版，比如Ubuntu 22.04，先看有哪些版本可选：
wsl --list --online然后指定安装：
wsl --install -d Ubuntu-22.04这套流程走通之后，你在开始菜单就能看到Ubuntu的入口，点进去就是Linux终端。
2.2 安装太慢？试试离线安装方案
wsl --install太慢是网上被吐槽最多的问题。我自己的经验是，与其死等在线下载，不如直接走离线安装，稳定可控，而且只需要做一次。
离线安装的核心思路分两步：装WSL本体，再单独装发行版。
第一步，如果系统里还没有WSL功能组件，先在管理员PowerShell里手动开启：
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart重启一遍，保证两个功能生效。
第二步，手动下载Ubuntu离线包。微软官方为每个发行版提供了单独的安装包，常见的下载地址是：
https://aka.ms/wslubuntu2204下载下来的通常是一个.appx或.msixbundle后缀的安装包。找到文件后，用PowerShell执行本地安装：
Add-AppxPackage .\Ubuntu2204.appx装完就能在开始菜单里找到Ubuntu并初始化。
如果这一步还是觉得麻烦，还有更“极客”的方式：直接下载Ubuntu的rootfs压缩包，然后用WSL导入功能创建发行版。这个“导入tar包”的技能其实也是后面迁移的核心操作，我放在第3节详细讲。离线安装看似多几步，但整个过程完全不依赖系统去商店下载，网络再差也能装，我实测下来非常稳。
2.3 多发行版管理和版本切换
一个Windows机器上可以同时装多个WSL发行版，这在做不同项目时很实用。比如我本机就同时有Ubuntu 22.04和Debian，前者跑日常开发，后者用来测试兼容性。
查看当前已安装的发行版：
wsl --list --verbose输出里会标明每个发行版名称、状态、版本号（是1还是2）。切换默认发行版：
wsl --set-default Ubuntu-22.04进入指定发行版：
wsl -d Debian这些命令我建议你记下来，因为迁移、多发行版管理、后面Docker排查都会反复用到。装好之后别忘了换软件源，国内访问Ubuntu官方源经常慢，换成阿里云或清华源能快很多，命令我就不贴了（每家源配置大同小异），但这一步绝对是提升体验的关键操作。
3. 系统迁移：把WSL从C盘搬家到D盘
3.1 为什么要迁移：C盘空间和性能
WSL用起来很爽，但有一个让所有人头疼的问题：默认装完它会把整个Linux文件系统塞进C盘一个叫ext4.vhdx的虚拟磁盘文件里。这个文件的位置长这样：
C:\Users\你的用户名\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu22.04...\LocalState\ext4.vhdx这个文件有个特性：只增不减。你在WSL里装了一堆包、拉了几个大仓库、跑过一次Docker镜像，它还往上膨胀，直到撑满C盘。我曾经有次在WSL里装了一个conda环境加一套PyTorch，几天下来这个vhdx文件从3GB涨到了27GB，而C盘本身也就120GB的空余。而且虚拟磁盘文件在机械硬盘或较慢SSD上拖累整体读写速度，迁移到D盘能一举解决空间和性能问题。
另外，迁移本身也是一种备份。把系统导出成一个tar包，就好比给整个Linux环境拍了张快照，即使Windows崩溃、重装系统，只要这个tar包还在，随时能恢复。
3.2 迁移实操：导出→移除→导入
强烈建议在迁移之前，先对WSL里的重要数据做好确认，最好自己通过Git把代码仓库先推到远程。迁移本身虽然不会动文件，但万一中途断电、路径写错，损失就大了。
第一步，完全关闭WSL：
wsl --shutdown这个命令会立刻停止所有运行中的WSL虚拟机，别跳过它。不关闭的话，虚拟磁盘文件可能处于占用状态，导出时会报错。
第二步，导出当前发行版为一个tar包。比如我想把Ubuntu-22.04导出，就执行：
wsl --export Ubuntu-22.04 D:\wsl-backup\ubuntu2204.tar这个tar包就是你的完整Linux环境，包括所有文件、配置、已装的软件。首次导出会花几分钟，文件有十几GB也很正常。
第三步，注销当前的发行版，释放C盘空间：
wsl --unregister Ubuntu-22.04注意，unregister这个名字听起来很轻，实际上它会删掉WSL里这个发行版的所有数据。导出的tar包如果没生成完毕或者没成功复制走，这步就变成灾难了，所以做之前一定再检查一遍第二步的tar文件大小是否正常。
第四步，重新导入到目标盘。在D盘建一个目录，比如D:\WSL\Ubuntu2204，然后执行：
wsl --import Ubuntu-2204 D:\WSL\Ubuntu2204 D:\wsl-backup\ubuntu2204.tar --version 2这里第一个参数是新的发行版名字，可以跟之前不一样（我这里用了Ubuntu-2204）；第二个参数是vhdx新家目录；第三个参数是tar包路径；最后指定版本号为2。导入完成之后，可以在wsl -d Ubuntu-2204进入系统，再确认C盘空间确实释放了。
3.3 迁移后必做的配置：默认用户和磁盘瘦身
导入之后你会发现一个尴尬问题：默认用户变成了root。原因很简单，tar包里的用户信息没有跟Windows下的“默认用户”绑定在一起，导入后的发行版不知道该用哪个普通用户登录。解决办法是写一个/etc/wsl.conf文件。在WSL里执行：
sudo vim /etc/wsl.conf写入：
[user] default=你的用户名然后在Windows侧执行wsl --shutdown再重新进入，默认用户就恢复成原来的普通用户了。
还有一个很多人不知道的好功能：新版WSL支持把虚拟磁盘设为“稀疏（sparse）”模式，用多少占多少，C盘或者D盘不容易被vhdx无限撑大。执行：
wsl --manage Ubuntu-2204 --set-sparse true如果你已经发现vhdx很大但又不想重新迁移，也可以先wsl --shutdown，然后用管理员PowerShell跑diskpart，手动对vhdx执行压缩（compact vdisk）。命令网上有现成的，我就不重复了，记住“先关机再压缩”这个核心原则就行。
4. 日常开发体验调优：VSCode、字体、Docker与CUDA
4.1 VSCode里用WSL开发的正确姿势
很多人装完WSL只在开始菜单里点开那个黑色终端窗口，这其实浪费了一大半潜力。真正舒服的用法是把VSCode和WSL接起来，让整个IDE跑在Linux环境里。
做法很简单：在VSCode扩展市场安装官方插件“WSL”。装好之后，VSCode左下角会出现一个绿色的按钮“打开远程窗口”，点它并选择“连接到WSL”，然后选择你的发行版。连接成功后，左下角会变成“WSL: Ubuntu-22.04”，这时候你在VSCode里打开的任何项目、跑的终端命令、装的Python环境，全都基于WSL里的Linux环境。
为什么会推荐这个方案？举个例子，你用Windows原生VSCode调试Python项目，如果项目里用到了某些Linux专属依赖，Windows环境往往装不上，还得开虚拟机或连服务器。用WSL插件之后，VSCode直接把插件、终端、调试器都跑在WSL的Linux环境里，Windows侧只需保留一个VSCode客户端壳，体验几乎跟原生Linux开发一样。而且在WSL2里文件读写、npm安装、编译速度都明显快于Windows侧，尤其对前端项目和Python项目。
4.2 最接近macOS体验的终端字体配置
之前有个热搜词专门提到“WSL Ubuntu写代码最推荐的字体接近macOS的体验”，一看就是被Windows默认的Consolas折磨过的人。WSL终端默认字体确实偏窄、偏拥挤，显示中文还容易出现半个字的尴尬。我自己折腾过一段时间字体，最后的结论是：最接近macOS代码体感的字体组合是“更纱黑体（Sarasa Term SC）搭配JetBrains Mono”。
更纱黑体是中文用户写代码的“神字体”，它解决了等宽字体无法显示中文或中文发虚的问题，中文笔画清晰、间距舒适。JetBrains Mono则是JetBrains家出品的英文代码字体，连字符（ligature）设计非常漂亮，圆润、辨识度高。组合起来的视觉效果接近macOS上常见的菜单栏字体+等宽代码字体搭配。
配置方法分两步。第一步，在Windows终端（Windows Terminal）设置里，打开设置 → 配置文件 → 默认值 → 外观 → 字体，选择“Sarasa Term SC”。如果你用的是旧版控制台窗口，可以在“默认值 → 外观 → 字体”里同样调整。第二步，如果你希望VSCode里也用这个组合，在VSCode的settings.json里加入：
"editor.fontFamily": "'JetBrains Mono', 'Sarasa Term SC', Consolas, monospace", "editor.fontLigatures": true,顺便说一句，字体文件可以直接从GitHub Release页下载，把“Sarasa Term SC”解压后右键安装所有TTF文件即可。这绝对是回报率最高的一次终端外观改造。
4.3 Docker Desktop弹出WSL报错的排查思路
“Docker Desktop there was a problem with WSL”是出现频率极高的报错，基本可以排进WSL相关问题的前三名。这个报错的原因有很多，但绝大多数是因为Docker Desktop默认使用WSL 2后端，而你的WSL环境状态不对。
我遇到过一次比较典型的情形：电脑休眠唤醒后，Docker Desktop突然报这个错误。最先要做的是重启WSL：
wsl --shutdown然后再启动Docker Desktop，很多时候问题就解决了。如果重启后依然报错，接着执行：
wsl --update更新WSL内核。如果还是不行，去“控制面板 → 程序 → 启用或关闭Windows功能”确认“虚拟机平台”依然处于开启状态，有时候Windows更新会把它关掉而不自知。最后一个大招是在Docker Desktop的设置里，把“Use the WSL 2 based engine”取消勾选再重新勾选，让它重新初始化WSL集成。这个报错通常不会牵扯更深层问题，不用慌。
另外，如果你发现Docker镜像和数据把C盘占满了，可以在Docker Desktop的设置中修改“Disk image location”，把wsl的docker-data目录整体迁移到D盘。注意，改之前要把所有容器清理干净，否则迁移过程会卡住。
4.4 WSL里装CUDA的注意事项
很多做深度学习的同学想在WSL里用GPU，这一点WSL 2已经支持得很好，但有个典型的认知误区：以为要在WSL里安装NVIDIA驱动。实际上正确的做法是在Windows侧安装支持WSL的NVIDIA驱动，然后WSL内部的Linux环境会自动复用这块GPU。
具体操作是：先在Windows下从NVIDIA官网下载最新的驱动包（GeForce或Studio版，新版驱动都带WSL支持），正常安装完成。然后进入WSL，不需要装驱动，直接在终端输入：
nvidia-smi如果显示你的GPU型号和显存信息，就说明GPU直通成功了。之后想用PyTorch，就在WSL里装显卡版PyTorch或conda安装cudatoolkit。如果只想加快Python的数值计算，甚至可以只在conda环境里装cudatoolkit，完全不碰CUDA toolkit完整包，省时省力。
注意，WSL里的CUDA版本不需要跟Windows侧驱动版本完全对应，驱动会做兼容层，别因为版本对不上就反复重装驱动。还有一点，WSL里的GPU显存和Windows共享物理显存，别把单次batch size拉得太高，容易OOM。
5. 高频问题实战排查：从安装报错到日常使用
5.1 安装阶段问题速查
我在安装和使用WSL的过程中，踩过的坑远比看过的文档多。整理一个高频问题速查表，直接对照处理，比每次瞎搜要高效得多。
| 问题现象 | 最常见原因 | 解决方案 |
|---|---|---|
| wsl --install卡住或太慢 | 网络到微软服务器不稳定 | 用wsl --install --no-distribution装组件，再离线安装发行版 |
| Windows提示找不到wsl命令 | 系统版本过旧或功能未开启 | 升级到Win10 2004+，用dism命令开启两个功能后重启 |
| 提示“your version of WSL is too old” | WSL内核组件版本过低 | 执行wsl --update或在商店升级WSL |
| 安装时要求重启但重启后没反应 | 虚拟化未开启 | 进BIOS打开VT-x或SVM |
| Ubuntu窗口打开后一直黑屏或闪退 | 发行版初始化失败 | 先wsl --shutdown，执行wsl --unregister后重新导入tar包 |
5.2 迁移和使用阶段问题速查
| 问题现象 | 最常见原因 | 解决方案 |
|---|---|---|
| 迁移后默认用户变成root | tar包重新导入后用户绑定丢失 | 在/etc/wsl.conf写[user] default=你的用户名 |
| WSL虚拟磁盘越来越大 | 写入量多、文件不回收 | wsl --shutdown后用diskpart执行compact，或启用sparse模式 |
| docker-desktop数据占用C盘 | Docker Desktop默认数据目录在C盘 | 在Docker Desktop设置里修改disk image location |
| WSL访问Windows文件速度慢 | 跨文件系统读写性能损耗 | 代码放到WSL内部文件系统，不要放在/mnt/c下频繁编译 |
| WSL与Windows剪贴板无法共享 | 剪贴板集成组件异常 | wsl --shutdown后重启WSL，通常能恢复 |
| 导入发行版后开始菜单没有图标 | --import方式创建的发行版没有商店入口 | 直接用wsl -d 发行版名进入，不影响使用 |
5.3 硬件和系统异常类排查
有些热搜词其实是把WSL和Windows系统本身的故障联系在了一起，比如“Windows无法启动这个硬件设备（代码50）”、“由于配置信息（注册表中的）不完整或已损坏”。如果这些报错恰好出现在WSL安装或运行后，大概率是Windows驱动状态混乱，不完全是WSL的锅。
我的处理经验是分三步：先执行wsl --shutdown，把WSL虚拟化资源全部释放；然后打开“设备管理器”，找到报错设备，右键卸载并重启让Windows重新扫描安装驱动；如果依然不行，再检查事件查看器里的安全日志和系统日志，定位是不是某次Windows更新或驱动更新引起了冲突。这类问题本身不复杂，但容易让人误判为“WSL把系统弄坏了”。我在写这篇内容时专门回顾了几次排查记录，核心原则是先排除WSL占用资源的影响，再去碰驱动和注册表。
另外，如果你装了C盘之外的WSL发行版，遇到系统重启后wsl命令找不到发行版，也别急着重新导入。先检查D盘或E盘的目标目录里vhdx文件是否还在，然后执行：
wsl --list --verbose看能否正常列出。很多时候只是Windows没有自动挂载，执行wsl --mount或直接在命令行带路径进入即可恢复。
最后再说说安装WSL这件事我最想分享的体会：不要把它当成“虚拟机替代品”来纠结，它真正的价值在于让Windows和Linux从“二选一”变成了“同时存在、随时切换”的开发环境。搞定离线安装和跨盘迁移这两件事，后边几乎所有日常问题都顺着这个思路迎刃而解了。如果看完这篇你还是想先装一把试试，那就直接来，实际用两个礼拜，比任何文档都管用。
