Windows 11 上装 Linux 子系统这件事，我在不同机器上大概做过十几次：有厂商预装系统塞满全家桶的开发本，有自己装的纯净系统，也有常年不关机的小主机。同样是敲一句wsl --install，有的机器三分钟就进到 Ubuntu 的命令行，有的机器卡在0x80370102上半个小时动不了。差别不在那句命令本身，而在主板的虚拟化开关有没有开、系统的可选组件有没有被精简、以及安全软件有没有顺手把虚拟网卡拦下来。这篇就把 WSL2 从安装到日常使用这条链路拆开讲，重点放在那些文档里不写、但真会卡住人的地方。
内容适合两类人：一是没装过、想一次性装对的；二是已经装上了但用得别扭的，比如代码扔在/mnt/c里npm install慢到怀疑人生，或者服务明明起来了 Windows 浏览器却打不开。往下看之前先记住一句：WSL2 是跑在轻量虚拟机里的真 Linux 内核，不是套在 Windows 上的一层壳，这个认知决定了后面所有的性能判断和排障思路。
1. 先把 WSL2 的位置摆正：它到底是什么，不是什么
很多人第一次接触 WSL 是听到“Windows 能跑 Linux 命令了”，于是默认它就是一个模拟器或者一层兼容层。这个理解放在 WSL1 上基本成立，放在 WSL2 上就完全跑偏了。搞清楚这两代的区别，能让你在遇到文件慢、内存高、网络不通这些问题时，第一反应就不是“系统有 bug”，而是“本来就该这样”。
1.1 从 WSL1 到 WSL2，中间换掉的是整个执行模型
WSL1 的实现方式是在 NT 内核里加了一套系统调用翻译层，Linux 程序发出来的fork、open、mmap这些调用，被实时翻译成 Windows 对应的内核调用。好处是文件和网络跟 Windows 完全共享，/mnt/c和C:\指向同一份数据，速度没有损耗；坏处是翻译不可能做到百分之百等价，一些依赖特定内核行为的程序会诡异失败，比如某些数据库、某些容器运行时、某些需要ptrace或者namespace的工具。
WSL2 换了个思路：直接在 Hyper-V 的虚拟化能力之上启一台极轻量的虚拟机，里面跑的是官方编译的真实 Linux 内核，发行版是货真价实的 Ubuntu、Debian 或者 Alpine。你在里面uname -r看到的是内核版本号，不是模拟出来的字符串；iptables、cgroup、namespace这些都能正常用。它跟传统虚拟机的区别在于，这台虚拟机启动是秒级的、默认不占固定内存、跟宿主机的集成做得很深（剪贴板、文件系统、端口都是打通或者半打通的）。
代价也随之而来：因为内核和文件系统都是真的，跨系统访问文件就必须走一层协议，性能损耗就从这里产生。这是后面所有“为什么这么慢”的总根源，先记住。
| 维度 | WSL1 | WSL2 |
|---|---|---|
| 内核 | 系统调用翻译层 | 完整真实 Linux 内核 |
| 跨系统文件读写 | 几乎无损 | 有明显开销（走 9P 协议） |
| 兼容性 | 部分系统调用缺失 | 基本等同原生 Linux |
| 内存模型 | 与 Windows 共享 | 独立虚拟机，动态占用 |
| 网络 | 与 Windows 同一栈 | 独立虚拟网卡，NAT 或镜像模式 |
| 启动开销 | 无 | 首次启动需要拉起虚拟机 |
1.2 双系统、传统虚拟机、WSL2，三种方案各自的适用面
双系统胜在纯粹，硬件资源全给一个系统，适合做驱动开发、内核模块调试、需要独占 GPU 的场景。代价是切换成本高，重启一次两分钟，日常在“我要写代码”和“我要开会议软件”之间来回横跳的人根本受不了。
传统虚拟机（VMware、VirtualBox、Hyper-V 完整虚拟机）胜在隔离彻底、快照方便、可以同时开好几个不同发行版。代价是资源分配是静态的，你给了 8G 内存，那 8G 在虚拟机关掉之前就一直被占着；文件互访依赖共享目录，配置起来也麻烦。
WSL2 的位置在中间偏轻量那一侧：启动快、内存按需增长、跟 Windows 的集成度高到可以互相调命令（Windows 里敲wsl ls，Linux 里敲explorer.exe .），适合绝大多数日常开发——写后端、跑前端构建、做数据处理、学 Linux 命令。它不适合的场景也很明确：需要加载自定义内核模块、需要嵌套虚拟化跑完整 Kubernetes 集群、需要独占访问某个 USB 设备的，老老实实上完整虚拟机或者双系统。
我自己的机器上是这么分工的：日常编码、跑单元测试、连远程数据库全在 WSL2 里，随开随关；需要做完整容器编排实验的时候再开一台完整虚拟机。两套不冲突，反而互补。
2. 装之前的三项体检，跳过的话后面全是难以解释的报错
安装失败绝大多数不是命令敲错了，而是机器的前置状态不满足。这一步花五分钟确认，能省掉后面一小时对着错误码瞎搜的时间。
2.1 版本号、虚拟化开关与 CPU 特性
第一步看系统版本。Win + R输入winver，弹出的窗口里看内部版本号。WSL2 要求 Windows 11 全系支持，Windows 10 那边需要 19041 及以上。如果版本号低于要求，先走系统更新，别急着折腾 WSL，白费功夫。
第二步看 CPU 虚拟化有没有开。打开任务管理器，切到“性能”页，点 CPU，右下角会有一行“虚拟化：已启用 / 已禁用”。如果显示已禁用，就得进 BIOS 打开。英特尔平台找Intel Virtualization Technology或者VT-x，AMD 平台找SVM Mode，不同主板位置不一样，一般在 Advanced 或者 CPU Configuration 下面。这一步很多人会漏，因为它不在操作系统里，任何一条 Windows 命令都查不出来到底开没开。
第三步确认 Windows 的虚拟机监控程序没有跟第三方虚拟机软件打架。如果机器上装过某些老版本的虚拟机软件，它们可能开启了基于虚拟化的兼容模式，导致 Hyper-V 层起不来。这种情况在系统信息里能看到“检测到虚拟机监控程序”之类的提示，处理办法是把冲突软件的虚拟化加速关掉，或者干脆先卸载。
注意：Windows 11 家庭版一样能装 WSL2。网上很多老帖子说必须专业版才能用 Hyper-V，那是把“Hyper-V 管理器和完整虚拟机”跟“WSL2 依赖的虚拟机平台”混为一谈了，家庭版只是没有管理器的图形界面，底层能力是有的。
2.2 两个可选组件的开启顺序与命令行写法
WSL2 依赖两个 Windows 可选功能：Microsoft-Windows-Subsystem-Linux（子系统本体）和VirtualMachinePlatform（虚拟机平台）。图形界面路径是“控制面板 → 程序和功能 → 启用或关闭 Windows 功能”，勾上这两项后重启。命令行更干脆，以管理员身份打开 PowerShell：
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart两条命令跑完必须重启一次，这一步没有捷径。我见过有人跑完不重启就去执行wsl --install，然后报一堆组件未启用的错，回头又去网上找偏方，其实是少了一次重启。重启之后再用wsl --set-default-version 2把默认版本定成 2，免得后面新装的发行版默认还是 1。
2.3 被精简系统、组策略和企业安全软件挡住的情况
有一类机器特别难缠：预装的精简版系统，镜像制作者把“适用于 Linux 的 Windows 子系统”这个组件直接删掉了，dism执行时返回“找不到功能”。这种没有优雅解法，要么找完整镜像重装系统，要么用后面提到的手动安装内核包的路子绕过去，但成功率不保证。
还有一类是企业环境，组策略里禁用了系统自带的应用商店，或者限制了可选功能的启用。表现是从商店点安装没反应，或者安装到一半中断。这时候优先找 IT 要管理员权限和策略豁免，别自己硬刚注册表。
第三类是安全软件。某些带主动防御的软件会拦截虚拟网卡的创建，症状是安装看起来成功了，但wsl一启动就报网络相关错误，或者启动后完全没网。处理办法是把 WSL 相关的进程和虚拟网卡加进白名单，或者安装期间临时退出防护。
3. 三条安装路径：什么场景该走哪一条
同样是装 WSL2，官方其实留了好几个入口，适用场景差别不小。选错路径不是装不上，而是会在中途遇到莫名其妙的卡点。
3.1 一条命令的极简路径及其边界
在较新的 Windows 11 上，管理员 PowerShell 里一句就够：
wsl --install这条命令会自动开启所需组件、下载最新内核、拉取默认发行版（通常是 Ubuntu）、设好默认版本为 2，然后提示你重启。重启之后首次启动会让你设置用户名和密码，走完就进 shell 了。
这条路径最省事，但有三个边界要知道。第一，它依赖网络能访问官方分发渠道，网络受限时会卡在下载环节，表现是长时间无输出然后超时。第二，它默认装 Ubuntu，如果你想要别的发行版，得用wsl --install -d <发行版名>，先用wsl --list --online看看有哪些可选。第三，如果机器上已经装过旧版 WSL，这条命令可能因为状态冲突而失败，需要先wsl --update或者清理旧状态。
我在网络条件正常的机器上基本都走这条路，从敲命令到进 shell 十分钟以内，是最省心的。
3.2 手动分步：适合已经被折腾过的系统
如果wsl --install报错，或者系统状态不明，就拆开手动做，每一步都能验证结果：
- 按前面的
dism命令开启两个可选功能，重启。 - 下载并安装 WSL2 内核更新包（官方页面提供的
wsl_update_x64.msi），双击一路下一步。 wsl --set-default-version 2确认默认版本。wsl --list --online看可用发行版，wsl --install -d Ubuntu-22.04指定装。wsl --list --verbose检查状态列是不是Running、版本列是不是2。
分步做的好处是出错点清晰。比如卡在第 2 步，说明是内核包的问题；卡在第 4 步，说明是网络或者分发渠道的问题。比一句命令下去完全不知道哪里挂了要好排查得多。
3.3 离线环境与内网机器怎么办
完全断网或者只能访问内网的环境，思路是把“组件”和“发行版”分开准备。组件用系统镜像自带的dism源启用；内核更新包和发行版安装包（.appx或者.tar.gz形式的 rootfs）从能上网的机器上下好，拷过来。
其中发行版的 rootfs 压缩包最通用，拿到之后可以直接导入，完全绕开应用商店：
wsl --import MyUbuntu D:\wsl\MyUbuntu D:\wsl\ubuntu-rootfs.tar.gz --version 2--import这个子命令值得单独记一下，它不只能用于离线安装，日常做发行版备份、迁移到另一台机器、复制一份干净环境做测试，都是靠它。第一个参数是自己起的名字，第二个是虚拟磁盘存放目录，第三个是 rootfs 路径。导入完用wsl -d MyUbuntu启动即可。
提示：
--import进来的发行版默认以 root 登录，需要手动在/etc/wsl.conf里指定默认用户，否则每次都是 root，权限模型会跟你预期的不一样。
4. 第一次进 shell 之后，这几件事最好当场做完
装完能进 shell 只是能跑，离“顺手”还有段距离。下面这几项配置，早做早省事，拖着的话后面会以各种奇怪的形式找上门。
4.1 用户、密码、发行版管理的基础操作
首次启动设的用户名和密码是 Linux 侧的账号，跟 Windows 账号没有任何关系，忘了也不影响 Windows 登录，但会进不去 WSL。忘了的话，用 root 身份重置：
wsl -u root -d Ubuntu-22.04 passwd yourusername发行版多了之后，常用管理命令要熟：
| 操作 | 命令 |
|---|---|
| 列出已装发行版及版本 | wsl --list --verbose |
| 切换默认发行版 | wsl --set-default Ubuntu-22.04 |
| 单独关闭某个发行版 | wsl --terminate Ubuntu-22.04 |
| 关闭整个 WSL 虚拟机 | wsl --shutdown |
| 卸载发行版 | wsl --unregister Ubuntu-22.04 |
| 更新 WSL 本体 | wsl --update |
wsl --shutdown这个命令要养成习惯。改完配置文件、调完内存参数、遇到任何“改了没生效”的情况，先执行它再重启发行版。因为 WSL2 的虚拟机是常驻的，发行版的关闭不等于虚拟机关闭，很多全局配置必须整机重启才读得到。
另外提醒一句，--unregister是不可逆的，执行下去整个发行版的文件系统直接删掉，没有回收站。手滑之前先wsl --export备份一份。
4.2/etc/wsl.conf和.wslconfig的分工，这是最容易搞混的一组配置
这两个文件名长得像、作用也相关，但完全不是一个层级的东西，搞混了会白折腾很久。
/etc/wsl.conf在发行版内部，管的是这一个发行版的行为：默认登录用户、是否自动挂载 Windows 盘符、是否生成/etc/resolv.conf、是否启用 systemd、是否把 Windows 的 PATH 追加进来。
.wslconfig在 Windows 用户目录下（C:\Users\<你的用户名>\.wslconfig），管的是整台虚拟机的行为：内存上限、CPU 核数、交换分区大小、是否开启 localhost 端口转发、网络模式、内核启动参数。
# C:\Users\<用户名>\.wslconfig [wsl2] memory=8GB processors=4 swap=2GB localhostForwarding=true# /etc/wsl.conf [user] default=yourusername [automount] enabled=true options="metadata,umask=22,fmask=11" [boot] systemd=true [interop] appendWindowsPath=true改.wslconfig之后要wsl --shutdown再启动；改/etc/wsl.conf之后至少要wsl --terminate <发行版>。我遇到最多的情况是改完没重启，然后一口咬定“配置不生效”，其实文件压根没被重新读取。
memory=8GB这一行尤其值得加。默认情况下 WSL2 的内存上限是物理内存的一半，一台 32G 的机器上它可能吃到 16G，任务管理器里显示成一个叫vmmem的进程，看着像内存泄漏。设个硬上限能避免它把整机拖慢。
4.3 打开 systemd 之后，服务管理方式就正常了
早期 WSL 没有 systemd，systemctl命令直接报“System has not been booted with systemd”。这导致很多教程里的操作在 WSL 里做不了，比如systemctl enable开机自启、journalctl查日志。
现在只要在/etc/wsl.conf里加一段：
[boot] systemd=true然后wsl --shutdown重启发行版，systemctl就能正常用了。注意几个配套细节：启用 systemd 之后，WSL 的启动会慢一点点，因为要跑完整的 init 流程；另外某些老版本的 WSL 本体不支持这个选项，需要先wsl --update；还有，WSL 里的 systemd 不接管 Windows 侧的服务，别指望用它在开机时拉起需要跟 Windows 桌面交互的程序。
5. 文件放在哪：/mnt/c和 Linux 主目录之间的性能鸿沟
如果这篇只让我留一句话，我会留这句：把项目代码放在 Linux 侧的主目录里，不要放在/mnt/c下。这一条能解决 80% 的“WSL2 好慢”的抱怨。
5.1 跨系统文件访问为什么要多走一层协议
WSL2 里的 Linux 和 Windows 是两个独立系统，它们各自有各自的文件系统。当你在 Linux 里访问/mnt/c/Users/xxx/project，实际发生的事情是：Linux 的文件操作请求被转交给一个文件服务组件，由它去调用 Windows 的文件接口，再把结果原路返回。这个往返在单个大文件上还好，但在“打开几千个小文件”这种场景下，开销被放大得非常明显。
实测下来，同样一个前端项目，在/mnt/c下执行依赖安装，跟在 Linux 主目录下执行，耗时差距经常是几倍甚至十倍。git status在跨系统目录里点开一个稍大的仓库，转圈十几秒是常事，在主目录里基本瞬间返回。这不是磁盘慢，是协议栈的往返次数太多。
判断一个目录是不是跨系统挂载的，看mount输出或者直接df -h，看到带drvfs或者9p的就是。
5.2 代码该放哪一侧，以及两侧怎么互访
推荐的结构是这样：项目放在 Linux 主目录，比如~/projects/xxx；Windows 上装一个 VS Code，通过远程开发功能连进来编辑。这样文件读写全在 Linux 侧，编辑器界面在 Windows 侧，两边都拿到自己想要的东西，性能没有损耗。
从 Linux 访问 Windows 文件，用/mnt/c/...，适合偶尔拷个文件、读个配置，别用来做工程目录。从 Windows 访问 Linux 文件，在资源管理器地址栏输入\\wsl$\<发行版名>\home\<用户名>，或者在 Linux 里执行explorer.exe .直接弹窗，拷贝小文件很方便。
如果确实有些项目必须在 Windows 侧（比如依赖某些 Windows 专属工具链），那就接受性能代价，同时把能优化的地方优化掉：Git 配置里关掉文件模式检查、编辑器里排除node_modules之类的目录索引、构建工具的输出目录尽量少跨系统写。
# 在 Linux 侧给跨系统目录关闭文件模式检测 git config --global core.filemode false6. 网络这一层：NAT 模式下服务怎么被外面看见
WSL2 的网络默认是 NAT 模式，虚拟机有自己的虚拟网卡和内部 IP，跟 Windows 宿主不在同一个网段。这个设计导致端口访问、服务发现、局域网访问这几件事都要额外处理。
6.1 localhost 转发默认是开的，但不是万能的
大多数情况下，你不需要做任何配置。WSL2 里起了个监听 3000 端口的服务，Windows 浏览器访问http://localhost:3000直接就能打开，这是 localhost 转发在起作用，.wslconfig里的localhostForwarding=true就是控制它的（默认就是 true）。
不生效的情况主要有三类。一是服务只监听了127.0.0.1而不是0.0.0.0，某些框架默认绑回环地址，转发就接不上，改配置绑0.0.0.0。二是.wslconfig里手动关掉了转发。三是网络模式不是默认的 NAT，比如开了镜像模式但没重启。
如果确实需要让局域网里其他设备访问，纯 NAT 模式下得做端口映射：
# 以管理员身份运行，把宿主机 8080 转到 WSL 内部 8080 netsh interface portproxy add v4tov4 listenport=8080 listenaddress=0.0.0.0 connectport=8080 connectaddress=(wsl hostname -I).Trim()注意 WSL 的内部 IP 每次重启可能变化，这种映射不持久，机器重启后要重做。比较省事的办法是用镜像网络模式，在.wslconfig里加：
[wsl2] networkingMode=mirrored镜像模式下 WSL 直接共享 Windows 的网络接口，IP 地址跟宿主机一致，端口也不用转发，局域网访问直接就通。代价是要求系统版本较新，太老的构建不支持这个选项，加了也不生效。
6.2 DNS 解析抽风的排查顺序
症状很典型：ping 8.8.8.8通，ping baidu.com不通，apt update卡在解析域名。这说明网络层是通的，问题在 DNS。
WSL2 默认会自动生成/etc/resolv.conf，里面的 nameserver 指向虚拟网络的网关地址，由 Windows 侧代理解析。这个机制在大多数环境正常工作，但在切换网络（比如从公司网回家、从有线切无线）、或者安装了某些会改写网络配置的软件之后，会失效。
排查按这个顺序来：
cat /etc/resolv.conf看里面的地址是不是有效的网关地址。nslookup baidu.com看解析结果，如果不通，说明上游有问题。wsl --shutdown重启，很多时候重启就好了，因为会重新生成配置。- 反复出问题的话，关掉自动生成，手动写一个稳定的 DNS：
# /etc/wsl.conf [network] generateResolvConf=false然后手动维护/etc/resolv.conf，注意这个文件在关闭自动生成之后，重启容器或者重装发行版可能被重置，稳妥做法是在启动脚本里重新写一遍，或者用chattr +i锁住（锁住之后要改得先解锁，别把自己锁死）。
7. 排障实录：几个最常见卡点的排查链路
前面讲的都是“顺利路径”，实际动手时更常遇到的是报错。下面这几个是我踩过次数最多的，把完整排查过程写出来，遇到同类问题可以照着走。
7.10x80370102和0x8007019e这两个错误码
0x8007019e的意思是“适用于 Linux 的 Windows 子系统可选组件未启用”。看到这个就回去确认两个可选功能是不是真的开了、有没有重启。有一种阴间情况是功能列表里显示已勾选，但底层组件损坏，这时候先在功能列表里取消勾选、重启、再重新勾选、再重启，相当于重置一遍。
0x80370102的含义是“虚拟机无法启动，所需功能未安装”。这条报错指向的通常是虚拟化层：要么 BIOS 里的 VT-x / SVM 没开，要么开了但 Windows 的虚拟机监控程序没起来，要么这台机器本身跑在另一台虚拟机里而嵌套虚拟化没打开。
排查顺序：任务管理器确认虚拟化已启用 → 确认VirtualMachinePlatform已勾选并重启 → 如果是虚拟机里的系统，去宿主机的虚拟机设置里打开嵌套虚拟化 → 最后再怀疑安全软件拦截。我在一台云上的虚拟机上折腾过四十分钟，前面三步全对，最后发现是宿主机侧没开嵌套虚拟化，这个信息在系统内部完全查不到，只能去宿主机配置里看。
7.2vmmem吃内存和ext4.vhdx只涨不缩
vmmem是 WSL2 虚拟机在 Windows 侧的表现形式。它吃内存多有两层原因：一是 Linux 内核本身会用文件缓存，缓存不算“已用”但在任务管理器里算进去了，看着很吓人；二是 WSL2 在较老版本里确实不主动把空闲内存还给 Windows。
处理办法分两步。先设上限，在.wslconfig里写memory=8GB（按自己机器内存定，一般给 8G 到 16G 够用），然后wsl --shutdown。较新版本还支持自动回收，可以加一行autoMemoryReclaim=gradual，让它慢慢把空闲页还回去。
另一个常见现象是磁盘只涨不缩。WSL2 的磁盘是一个虚拟磁盘文件ext4.vhdx，你在里面装了东西它会变大，但删掉文件之后它不会自动变小，白占着 Windows 磁盘空间。压缩方式有几种，新版本直接支持：
wsl --manage Ubuntu-22.04 --set-sparse true或者用diskpart手动压缩：
wsl --shutdown diskpart # 进入交互后依次执行 select vdisk file="C:\Users\<用户名>\AppData\Local\Packages\<发行版包名>\LocalState\ext4.vhdx" attach vdisk readonly compact vdisk detach vdisk exit路径不好找的话，用Get-ChildItem -Path $env:LOCALAPPDATA\Packages -Recurse -Filter ext4.vhdx直接搜出来。压缩之前务必wsl --shutdown，虚拟磁盘正在被占用的时候操作会失败。
注意：压缩虚拟磁盘前先
wsl --export备份一份，这个操作本身是安全的，但一旦中途断电或者磁盘写满，损坏的虚拟磁盘很难修复。备份成本几分钟，修起来可能几小时。
7.3 系统时间漂移和长时间挂起后的异常
笔记本合盖休眠再打开，有时候会发现 WSL 里的时间慢了几小时甚至几天，apt报证书未生效、git报时间异常。原因是虚拟机在挂起期间时钟停了，恢复之后没有立刻跟宿主同步。
临时修一下：
sudo hwclock -s如果经常出现，检查一下 WSL 本体是不是旧版本，wsl --update更新一下通常能缓解。另外长时间挂起之后顺便重启一次wsl --shutdown，把虚拟机的状态整个刷一遍，比在旧状态上修修补补靠谱。
我个人的习惯是，机器合盖超过一天再打开，第一件事就是wsl --shutdown，然后再进项目。这几秒钟的代价，换来的是一整天不遇到莫名其妙的时间、网络、挂载问题。
最后分享一个我一直在用的小习惯：把常用的发行版导出成一个“干净基线”包存着，路径放在不那么占空间的盘上。哪天某个发行版被折腾坏了、依赖冲突解不开、或者想给新机器快速搭环境，直接wsl --import导入这个基线，五分钟就能得到一个干净可用的环境，比自己从头重装一遍省事得多。基线包不用经常更新，半年刷一次就行，重点是“能进 shell、基础工具齐、网络正常”，剩下的项目依赖在导入之后现装。
