呗老心眼极小早几年我还在Windows上装VMware虚拟机跑Ubuntu，公司发的笔记本只有16G内存，Win10一开机吃掉快一半，再拖一个虚拟机，风扇转得跟直升机似的。后来换了双系统？也不行——上班摸鱼刷网页、微信、QQ、办公套件全在Windows这边，来回重启根本不现实。直到Windows 10 2004版本之后自带的WSL（Windows Subsystem for Linux）彻底成熟，我才算找到了在Windows 上舒服地用Linux 的办法。
WSL简单说，就是微软把一套Linux内核和用户态环境做成了Windows的子系统，你不需要装虚拟机软件，不需要分区装双系统，直接在Windows里跑原生的Linux命令和工具，还能和Windows文件系统互相访问。本文我会从方案选型、安装避坑、日常配置、目录迁移、故障排查这几个维度展开，所有内容都基于Windows 10自带的WSL实际环境，适合刚入门的小白，也能给已经用了一段WSL但踩过坑的同学一些参考。
1. 为什么是WSL：我把三种方案都试过之后的选择
1.1 我最早用VMware跑Linux的场景
一开始我跟大多数人一样，图省事装VMware Workstation，再装一个Ubuntu镜像。虚拟机的好处是隔离干净，Windows出问题也不影响Linux，还能随便拍快照。但用了半年我发现几个很烦的问题：第一是启动慢，开个虚拟机少说三四十秒，进入桌面还要等；第二是内存占用大，Ubuntu桌面版本身要占2G左右，再加上虚拟机软件的开销，Windows这边明显变卡；第三是剪贴板和文件共享偶尔抽风，经常要在虚拟机和宿主机之间来回拷贝文件，体验很割裂。
我也试过装双系统，Ubuntu和Windows各占一块分区。双系统的性能确实最好，Linux能用满全部硬件资源，但你想想实际场景：开发的时候需要查一段资料切回Windows，重启一次；开个视频会议，Windows通知弹不出来，又得重启。来回折腾几次我就放弃了。对依赖Windows办公环境的人来说，双系统是种奢侈品，不是日常工具。
1.2 WSL 1和WSL 2的区别，选了哪个
WSL分两个大版本，WSL 1和WSL 2，不少人搞不清这俩的区别。
WSL 1的思路是做一个翻译层，把Linux的系统调用翻译成Windows NT内核能理解的调用，所以它不是一个真正的Linux内核。好处是启动速度极快，文件IO也快，因为直接操作Windows文件系统。但坏处是兼容性不完整，有些依赖内核特性的软件跑不起来，典型例子是Docker。
WSL 2则换了一套思路，它用微软的虚拟化平台跑一个真正的轻量级Linux内核，系统调用完全兼容，Docker可以直接跑。代价是跨文件系统IO变慢，而且需要CPU支持虚拟化并开启相关Windows功能。
我自己现在的选择很明确：默认用WSL 2，日常开发、跑容器都靠它。只有在需要频繁操作Windows目录下的文件时，才会临时切到WSL 1。比如有个项目代码放在D盘的Windows目录下，WSL 2访问/mnt/d下的文件，IO速度比较慢，这时候WSL 1反而更顺手。切换方式很简单：
powershell复制# 查看当前版本
wsl -l -v
# 把指定发行版切成WSL 1
wsl --set-version Ubuntu-24.04 1
# 切回WSL 2
wsl --set-version Ubuntu-24.04 2
1.3 WSL替代不了什么
用了这么久，我得说清楚WSL的边界，免得有人抱着过高期望进来然后骂娘。
WSL毕竟不是一台完整的物理机，它的systemd支持在WSL 2较新版本中虽然已经默认可用，但还是有些早期版本的发行版需要手动开启。如果你需要测试内核模块、需要硬件直通、需要USB设备透传，WSL做起来会很别扭——虽然USB可以配合usbipd工具用，但体验远不如虚拟机原生支持。
另外WSL跑图形界面应用虽然支持WSLg，但Windows 10上的WSLg默认可用性不如Windows 11，所以日常如果重度依赖Linux图形程序，还是老老实实开虚拟机。WSL适合的是命令行为主的开发场景，不是我全都要的万能方案。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 装之前先看这几个条件，否则后面全是坑
2.1 Windows版本和系统功能的硬要求
WSL对Windows 10的版本有硬性要求，这可能是很多人在安装时遇到莫名问题的根源。
WSL 2要求Windows 10版本在2004（build 19041）以上，建议直接上22H2。如果系统版本太老，你在PowerShell里输入wsl --install可能压根不识别这个命令。我帮朋友排查时就见过这种情况：他Windows 10还停留在1909，网上教程让敲wsl --install，敲完提示不是内部或外部命令。
这里顺便提一个相关的坑：如果Windows更新一直卡在某个进度（比如热词里经常看到22H2卡在30%），会直接影响系统补丁和功能的安装，WSL依赖的虚拟机平台组件可能也装不齐。遇到这种更新卡住的情况，不要急着重装系统，先清理一下Windows更新缓存，停掉Windows Update服务，删掉C:\Windows\SoftwareDistribution\Download下的内容再重新更新，大多数能解决。如果实在更新不上去，那WSL 2可能会处于装一半的状态，怎么弄都不顺。
确认版本没问题后，有两个Windows功能必须开启，管理员身份打开PowerShell执行：
powershell复制dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
执行完重启电脑。这里提醒一句：VirtualMachinePlatform是WSL 2的核心依赖，只开Linux子系统不开这个，WSL 2起不来。
2.2 wsl --install太慢或卡住怎么办
很多教程让你直接在PowerShell里执行wsl --install，然后等它自动下载。理论上它会帮你装好WSL组件并拉取默认的Ubuntu发行版，但实际操作中不少人会遇到下载特别慢、进度条不动的状况。
我自己的经验是不要干等。WSL本体安装通常很快，慢的是发行版下载。可以分两步走，先把WSL本体装好，再单独装发行版：
powershell复制# 只装WSL本体，不装任何Linux发行版
wsl --install --no-distribution
# 安装完重启后，手动更新内核
wsl --update
然后安装发行版时，不要用默认的Ubuntu，指定一个明确的版本反而更快：
powershell复制wsl --install -d Ubuntu-24.04
如果你指定版本还是慢，还有一个办法：去微软商店搜索Ubuntu 24.04，在商店页面里点击获取，让商店后台去下载，有时候比命令行下载快得多。商店装完以后，同样会出现在wsl -l -v列表里。
还有更省心的一种操作：去微软官方的WSL发行版下载页面，手动下载Ubuntu的.appx包，然后用Add-AppxPackage安装。这个方式适合公司电脑的商店被组策略关掉、或者命令行下载完全卡死的场景：
powershell复制Add-AppxPackage .\Ubuntu_2204.1.7.0_x64.appx
装完之后首次启动会让你创建用户名和密码。注意这个用户名和密码是Linux子系统内的，跟Windows账户没关系，密码输入时不回显是正常的。
2.3 默认装完的Ubuntu文件存在哪里
装完之后你可能会问：我装了这么个Linux系统，文件到底放哪了？WSL 2的发行版是一个虚拟磁盘文件（ext4.vhdx），放在：
code复制C:\Users\<你的Windows用户名>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu24.04LTS_xxxx\LocalState\ext4.vhdx
这个文件的体积就是你Linux系统里所有文件的合计大小。很多人用着用着发现C盘空间越来越小，一查就是它。后面第4节我会专门讲怎么迁移和瘦身。
3. 装完第一件事不是敲命令，是搞定这套配置
3.1 把apt源换掉，不然install能等到天荒地老
Ubuntu装完后默认的软件源是国外的服务器，在国内网络环境下执行sudo apt update，经常卡在某个地方半天不动。所以装完第一件事永远是换源。
我用的是清华TUNA镜像源，阿里云和网易的也可以，思路一样。Ubuntu 24.04和之前的版本在源配置上有点区别：22.04及以前用/etc/apt/sources.list，24.04换成了/etc/apt/sources.list.d/ubuntu.sources，格式是deb822格式。
先备份再修改，操作前备份永远是好习惯：
bash复制sudo cp /etc/apt/sources.list.d/ubuntu.sources /etc/apt/sources.list.d/ubuntu.sources.bak
然后编辑这个文件，把里面的URI地址从http://archive.ubuntu.com/ubuntu/和http://security.ubuntu.com/ubuntu/替换成镜像地址。为了省事，我直接sed替换：
bash复制sudo sed -i 's@http://archive.ubuntu.com/ubuntu/@https://mirrors.tuna.tsinghua.edu.cn/ubuntu/@g; s@http://security.ubuntu.com/ubuntu/@https://mirrors.tuna.tsinghua.edu.cn/ubuntu/@g' /etc/apt/sources.list.d/ubuntu.sources
替换完再执行：
bash复制sudo apt update && sudo apt upgrade -y
我实测下来，换源后apt update从原来的五六分钟缩短到十几秒，这才是能干活的状态。
3.2 配置systemd和默认用户，WSL用起来才不像半残
WSL 2较新版本已经支持systemd了，但有些发行版默认没开。systemd对日常使用太重要了——你要启动ssh服务、docker服务，都依赖它。在/etc/wsl.conf里配置：
ini复制[boot]
systemd=true
[user]
default=你的用户名
改完在PowerShell里执行wsl --shutdown，再重新进入WSL，生效。
[user]这个配置也很关键。尤其是后面做发行版导出和导入之后，默认用户经常会变成root，没有这个配置每次进终端都是root，容易误操作。写上default=用户名之后，进入WSL就是你自己的账户，sudo按需提权，干净。
3.3 终端和编辑器：VSCode远程接入WSL
WSL刚装完自带的终端是Windows Terminal，Win10上如果没装，建议从微软商店装一个Windows Terminal，多标签页、配色、字体渲染都比传统conhost好看不少。
但日常写代码，我用的是VSCode + Remote - WSL扩展。这是WSL使用体验质的飞跃的一环：在Windows侧装好VSCode，再装一个叫“WSL”的扩展（扩展名就是Remote - WSL，微软官方出的），然后在这个扩展里选择连接到WSL的发行版。
连接之后VSCode会作为WSL里的编辑器运行，左侧文件目录直接是Linux文件系统，终端也自动变成了WSL的bash。你在Windows侧装的插件可能不生效，需要重新在WSL侧装一遍针对WSL的插件，但体验非常接近原生Linux开发。
另外一个小技巧：在WSL终端里直接敲code .，会自动拉起Windows侧已经安装的VSCode并连接当前目录，省得来回点鼠标。
3.4 把常用开发环境一口气装齐
换完源、配好终端后，接下来就是把日常要用的工具装齐。这个列表可以参考：
bash复制# 基础编译工具
sudo apt install -y build-essential git curl wget
# Python
sudo apt install -y python3 python3-pip
# Node（用nvm安装，方便切换版本）
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
装完这些，大部分命令行开发场景就能跑了。顺便说个例子：很多做固件分析的朋友喜欢在WSL里用binwalk，这个工具依赖一堆Linux工具链，在Windows的Git Bash里跑经常缺这缺那，在WSL里包管理器一条命令全部搞定。WSL的Linux兼容性在这类场景下的优势非常明显。
如果你的工作涉及GPU计算，WSL 2还支持CUDA——在Windows侧装好NVIDIA驱动，WSL内部直接能用nvidia-smi，不需要在Linux里再装驱动，这个特性最初版本还不稳定，现在实测下来已经比较可靠。
4. 目录迁移和磁盘瘦身：C盘红了也别慌
4.1 把WSL整个发行版迁到D盘
如果你和我一样C盘是个小容量的固态盘，用WSL几个月后就会发现C盘空间告急。原因很简单：你apt装的包、拉下来的代码、Docker镜像全放在那个ext4.vhdx里，它只会越涨越大。
我推荐的做法是把整个发行版导出再导入到其他盘，操作思路是完整的迁移：
powershell复制# 1. 完全关闭WSL
wsl --shutdown
# 2. 导出当前Ubuntu发行版为tar包（时间取决于你的数据量，可能等几分钟）
wsl --export Ubuntu-24.04 D:\wsl\backup\ubuntu-2404.tar
# 3. 注销这个发行版（注意：这步会从WSL列表中移除该发行版）
wsl --unregister Ubuntu-24.04
# 4. 把刚才的tar包导入到新路径
wsl --import Ubuntu-24.04 D:\wsl\ubuntu-2404 D:\wsl\backup\ubuntu-2404.tar --version 2
注意wsl --import后面三个参数：第一个是新发行版的名字，第二个是存放虚拟磁盘的目标文件夹，第三个是tar包路径。执行完再去C盘看，那个Package目录下的vhdx已经不存在了，数据在D盘。
这里有个我踩过的坑：导入完成后重新进入WSL，默认用户会变成root，因为--import不保留原来默认用户的配置。解决方式就是我前面在wsl.conf里写的：
ini复制[user]
default=你的用户名
写完后wsl --shutdown再重新进入，用户就恢复正常。
4.2 给vhdx虚拟磁盘瘦身
WSL 2的vhdx有个特点：你删了文件，它不会自动把空间还给Windows。比如你在WSL里创建一个10G的文件然后删掉，Windows上看到的ext4.vhdx体积并不会变小。时间久了，这个文件会虚胖。
瘦身的原理是先把未使用的空间置零，再用diskpart压缩。步骤如下：
先在WSL里执行：
bash复制# 把未使用空间填零
sudo dd if=/dev/zero of=/tmp/zero bs=1M
sudo rm -f /tmp/zero
然后回到Windows，管理员身份打开命令行：
bash复制diskpart
在diskpart里执行：
bash复制select vdisk file="C:\Users\<用户名>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu24.04LTS_xxxx\LocalState\ext4.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk
等它跑完，再看vhdx文件大小，我实测一个用了20多个G的WSL，压缩后直接降到9G左右。如果你已经把发行版迁移到了D盘，记得把命令里的路径换成D盘的实际路径。
5. 高频问题的排查链路：从服务起不来排到正常干活
5.1 wsl --update提示“无法启动服务，原因可能是已被禁用或与其相关联的设备没有启动”
这个报错在热词里经常出现，我实际处理过两次，一次是朋友遇到，一次是我自己更新内核时碰到。完整排查链路往下看。
先说结论：这个提示大多不是WSL本身坏了，而是Windows服务层面的问题。排查要按顺序做：
第一步，Win+R输入services.msc打开服务管理器，找到LxssManager（旧版WSL的关键服务）和WslService（新版WSL的关键服务），看它们的状态。如果显示“已禁用”或者根本没启动，右键属性把启动类型改为“自动”或“手动”，然后点启动。WslService的启动类型一般默认是手动，但状态应该是“正在运行”。
第二步，服务正常还是报错，管理员身份打开PowerShell执行：
powershell复制wsl --update
看它是不是能正常下载安装内核更新包。如果卡在“正在安装: 适用于 Linux 的 Windows 子系统”这一步然后报错，多半是Windows功能里缺东西。
第三步，重新确认两个关键功能：
powershell复制dism.exe /online /get-featureinfo /featurename:Microsoft-Windows-Subsystem-Linux
dism.exe /online /get-featureinfo /featurename:VirtualMachinePlatform
查看状态是否为Enabled。如果不是，回到第2.1节开启功能并重启。
我朋友那台电脑最后的根因是：他装过精简版系统，WslService被安全软件禁用，重新启用服务之后wsl --update一次通过。另一台机器的原因是系统里残留了旧版WSL的内核驱动，新版更新时被安全软件拦截，把旧的关键项清理后重新更新内核解决。总之这个报错不要一上来就重装系统，按服务、功能、内核三步走，绝大多数能解决。
5.2 WSL 2起不来的常见根因：虚拟化没开
有时候安装一切正常，但一启动WSL 2就报：请启用虚拟机平台 Windows 功能并确保在 BIOS 中启用虚拟化。
WSL 2依赖CPU虚拟化技术，Intel的VT-x和AMD的SVM。打开任务管理器，切到“性能”标签，看左下角“虚拟化”是不是“已启用”。如果显示“已禁用”，就需要进BIOS开启。
不同品牌电脑BIOS入口不一样，大多是开机按Del或F2，找到Intel Virtualization Technology或者SVM Mode，设为Enabled，保存重启。这个操作对电脑没风险，但确实有朋友单位电脑的BIOS被锁了虚拟化，那就只能用WSL 1，或者跟IT管理员申请。
5.3 跨文件系统IO慢：文件到底应该放哪边
WSL 2最大的性能短板就是跨文件系统访问。你在WSL里访问/mnt/c、/mnt/d下的Windows目录，速度明显比访问Linux自己的文件系统慢，尤其是大量小文件读写，差距能到好几倍。
解决办法很简单，但很多人不知道：代码和项目文件放在Linux文件系统内，也就是/home/你的用户名/下面。Windows侧需要编辑时，不要通过/mnt/c去找，而是在Windows资源管理器地址栏输入\wsl$\Ubuntu-24.04\home\，通过UNC路径去访问Linux里的文件。这样就绕开了慢速的跨系统IO路径。
另一个容易忽略的坑是Windows Defender实时扫描会影响WSL性能。如果WSL目录下的编译和文件操作明显偏慢，可以把Linux虚拟磁盘目录加入Defender的排除项。换来的性能提升体感很明显，代价是C盘或D盘那个目录的实时保护变弱，自己权衡。
5.4 DNS解析异常：一项排查顺序分享
WSL里偶尔会出现apt update的时候DNS解析失败，报Temporary failure resolving。这个问题的根源是WSL 2也会读取Windows侧生成的/etc/resolv.conf，而某些网络环境下生成的DNS地址不可用。
排查顺序：先看/etc/resolv.conf内容：
bash复制cat /etc/resolv.conf
如果nameserver指向明显不对，可以临时改：
bash复制sudo nano /etc/resolv.conf
# 改成 8.8.8.8 或你所在网络环境的DNS
但重启WSL后这个文件会被重新生成。想永久固定，可以关闭WSL的自动生成，然后手动指定：
bash复制# /etc/wsl.conf
[network]
generateResolvConf = false
改完之后：
bash复制sudo rm /etc/resolv.conf
sudo nano /etc/resolv.conf
# 手动写入 nameserver 8.8.8.8
wsl --shutdown
再进来就不会被覆盖了。注意这种方式如果经常切换Wi-Fi环境，DNS可能要自己维护，适合公司或家庭固定网络场景。
我个人的体会是：WSL不是要替代一台真正的Linux服务器，而是让开发环境能无缝地活在Windows生态旁边，两边都别耽误。我用了两年多，从最初在WSL里连基础的systemctl都起不来，到现在systemd、Docker、CUDA、远程开发都能稳定用，这套Windows 10自带的子系统已经从“玩具”进化成了真正的生产力工具。最后再分享一个小技巧：在Windows Terminal里给WSL的Ubuntu设置单独的“启动目录”和配色方案，每次打开终端直接就进项目目录，比进bash再cd省事多了。