折腾过 Linux 的人应该都有类似经历：手头一台 Windows 10 电脑，却要跑 Linux 下的工具链，装双系统嫌切换麻烦，开个虚拟机又卡得连拖动窗口都掉帧。我前两年就因为频繁在 Windows 和 Ubuntu 之间来回重启，实在忍无可忍，才认认真真把 WSL（Windows Subsystem for Linux）这套方案捡起来研究。WSL 说白了就是让 Windows 直接跑一个真正的 Linux 发行版，不用额外装虚拟机，也省掉了双系统重启的折腾。这篇文章记录的是我在 Windows 10 下启用 WSL 并安装 Ubuntu 22.04 的完整过程，从系统检查、功能开启、内核更新，到 Ubuntu 22.04 安装、初始化、软件源配置、磁盘迁移，再到我踩过的各种报错。适合谁看？准备在 Windows 上搭建 Linux 开发环境的学生、前端/后端/运维工程师，以及想在 WSL 里跑深度学习但不想放弃 Windows 桌面的朋友。
1. 动手前先搞清三件事：系统版本、虚拟化和 WSL 版本选择
1.1 你的 Windows 10 版本够不够用
WSL 2 对 Windows 10 有版本要求，这是很多新手一上来就栽跟头的地方。WSL 1 早在 2016 年就随着 Win10 1607 推出了，但 WSL 2 因为需要虚拟机平台支持，起步门槛是 Windows 10 版本 2004（内部版本号 19041）或者更高。如果你用的是比较老的 LTSC 或者长期没更新的版本，那就得先系统更新再折腾 WSL。
最快的检查方式是键盘按 Win + R，输入 winver，回车后会弹出一个关于 Windows 的小窗口，里面会写清楚版本号和内部版本号。我见过有人拿 1909 的机器硬着头皮跑 WSL 2，结果各种内核报错，折腾半天最后还是先升级了系统。虽然 1903/1909 部分版本也能手动支持 WSL 2，但体验远不如 2004 之后的流程顺畅，我建议直接一步到位升到 Windows 10 22H2，官方支持周期也长一些。
还有一点容易被忽略：WSL 2 依赖硬件虚拟化能力（Intel VT-x 或 AMD-V），不是所有 CPU 都默认打开了这个开关。你可以在任务管理器的"性能"标签页里看 CPU 那一栏是否有"虚拟化：已启用"的字样。如果显示已禁用，就得进 BIOS 找 Intel Virtualization Technology / SVM Mode 之类的选项把它打开，这一步不做后面 100% 会报错。
1.2 检查虚拟化是否可用
上面说的虚拟化开关，是 WSL 2 的硬性条件。因为 WSL 2 本质上是微软把 Hyper-V 的轻量化虚拟机技术拿过来给 Linux 子系统用，底层的 VM 组件一旦发现硬件虚拟化没开，就会直接罢工。
如果你不想进 BIOS，也可以先用命令看一眼当前系统状态。管理员身份打开命令提示符或 PowerShell，执行 systeminfo，拉到靠后的位置会有一行"Hyper-V 要求"，里面有四个项目：VM 监视器模式扩展、虚拟化固件中已启用虚拟化、二级地址转换、数据执行保护。只要这四个里有一个显示"否"，基本可以断定是 BIOS 层面没开，或者是旧 CPU 不支持，就得开机进 BIOS 处理了。
我踩过一次比较隐蔽的坑：电脑是 AMD 平台，BIOS 里叫 SVM Mode，默认就是禁用状态。Intel 平台叫 VT-x 或者 VT-d，名字五花八门。所以建议动手前先系统性地把这一项确认好，否则后面所有安装步骤看着都没问题，但一启动 Ubuntu 就报 0x80370114，非常磨人。
1.3 WSL 1 和 WSL 2，选哪个更合适
WSL 1 和 WSL 2 到底差在哪？简单说，WSL 1 是把 Linux 系统调用翻译成 Windows 内核调用的一层"翻译器"，没有完整的 Linux 内核，所以启动快、文件性能好，但兼容性差，很多 Linux 软件跑不起来。WSL 2 则是一个真正的轻量级虚拟机，里面运行着完整的 Linux 内核，兼容性大幅提升，Docker、PyTorch、CUDA 这些常年不兼容 Windows 的东西都能跑。
代价是 WSL 2 会占用更多内存，而且跨文件系统的读写性能要比 WSL 1 慢不少。如果你只是想在 Windows 里敲几个 Linux 命令、编译点小程序，WSL 1 也行；但如果要跑 Docker、做后端开发、装机器学习框架，WSL 2 几乎是必选。我的建议很直接：没有特殊理由，统一选 WSL 2 就行。微软把 WSL 2 设置成默认版本已经很久了，后续生态也基本围绕 WSL 2 展开。
2. 一步步行 I：启用 WSL 功能与更新内核
2.1 以管理员身份打开 PowerShell
接下来是实际操作环节。WSL 需要给 Windows 修改系统功能，所以终端必须用管理员身份运行。我的习惯是直接在开始菜单搜索"PowerShell"，右键选择"以管理员身份运行"，顺手把终端标到任务栏上，后面重启完还要用。
这里有个细节：系统里可能有 Windows PowerShell 和 Windows Terminal 两套东西。你只需要确保打开窗口的标题栏显示"管理员"字样即可。后面的操作在命令提示符里也一样，但 PowerShell 对命令的兼容性更好，统一在 PowerShell 里跑比较省心。
2.2 启用两个关键 Windows 功能
启用 WSL 需要打开两个系统功能：一个是“适用于 Linux 的 Windows 子系统”，另一个是“虚拟机平台”。你也可以走图形界面：控制面板 -> 程序和功能 -> 启用或关闭 Windows 功能，勾选这两个选项后重启。但既然是写给爱敲命令的人看的，我直接用 dism 命令解决。
在管理员 PowerShell 里按顺序执行下面两条命令：
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart/norestart 参数的意思是不立即重启，两条命令都跑完以后再手动重启。如果只开了其中一个就急着安装，后面启动发行版时很容易碰到"未启用虚拟机平台"的错误。另外，如果系统更新策略比较特殊，也可以去控制面板勾选功能，效果一样，没有谁更好一说。
重启完成之后，可以先验证一下功能有没有生效。打开 PowerShell 执行wsl --status或wsl --version，如果提示的是"适用于 Linux 的 Windows 子系统没有已安装的分发版"这类信息，说明 WSL 本身已经就绪，只差装发行版了。如果提示没有这个命令，功能可能没有正常启用，重新执行一次 dism 命令再重启。
2.3 安装 WSL2 内核更新包
这一步是许多新手会忽略的。WSL 2 和 WSL 1 不一样，它需要一个额外的内核更新包，这个包不会因为启用了功能就自动出现。微软官方提供名为 "wsl_update_x64.msi" 的安装文件，去官网搜索 WSL2 Linux 内核更新包，下载对应版本（x64 机器就下 x64）后双击安装即可。
安装过程非常快，本质就是把一个 Linux 内核放到 Windows 的固定位置。装完之后建议再执行一次wsl --set-default-version 2，把默认的 WSL 版本锁定在 2。这个命令输出的提示我们选择 2。
这个命令坑点也很多：如果你只装了 WSL 1，却在某一步执行了--set-default-version 2，随后安装的发行版默认全跑 WSL 2；但如果发行版已经装好，想从 WSL 1 切换到 WSL 2，需要单独用wsl --set-version <发行版名> 2来转换。这个过程会重新生成一个 WSL 2 虚拟机，耗时比想象中长，而且会占用额外的磁盘空间。
2.4 设置默认 WSL 版本
执行wsl --set-default-version 2后，系统会记住"以后新装的发行版都默认使用 WSL 2"。这一步强烈建议做，因为默认情况下部分 Windows 10 版本可能把 WSL 1 作为默认加载模式，装完才发现跑的环境不对，又要手动转版本，纯属给自己找麻烦。
设置完成后，可以顺手跑一下wsl --list --verbose或者wsl -l -v查看发行版状态和版本。虽然此时列表还是空的，但至少要确保命令不报错。如果wsl --set-default-version 2报错说需要"虚拟机平台"，说明第二步功能没启用全，回炉重造。
3. 安装 Ubuntu 22.04 并完成首启动配置
3.1 从 Microsoft Store 安装
完成前面的准备工作后，安装 Ubuntu 22.04 就简单了。最省事的方式是通过微软商店安装：打开 Microsoft Store，搜索 "Ubuntu 22.04"，找到由 Canonical 发布的那个应用安装即可。商店里会同时出现 Ubuntu 22.04.2 LTS 或 Ubuntu 22.04.3 LTS 之类的版本，选最新小版本没问题，它们都属于 22.04 LTS 系列。
如果你不喜欢商店，或者商店本身打不开，还有命令安装的方式。在管理员 PowerShell 里执行：
wsl --install -d Ubuntu-22.04这条命令会自动完成下载和安装。注意wsl --install这个子命令在较新的 Windows 10 上才支持，如果你的系统版本较旧，就老实走微软商店路线。
安装结束后会在开始菜单里出现一个 Ubuntu 22.04.xx LTS 的图标，第一次点击启动它会进入初始化流程。这个初始化比想象中慢，因为要解压整个根文件系统，期间终端会显示一行 "Installing, this may take a few minutes..."，耐心等就行，不用反复点别的按钮。
3.2 首次启动：创建用户名和密码
初始化完成后，Ubuntu 会提示你创建一个 UNIX 用户名和密码。这里有个很多人的认知误区：Linux 的传统是不推荐直接用 root 用户日常操作，Ubuntu 默认也禁用了 root 登录，所以这里创建的是普通用户，但这个用户默认在 sudo 组里，可以随时随地提权。用户名建议用小写字母，不要带空格和特殊符号，比如 john、dev 这种。
密码输入时屏幕不会有任何反馈，这是正常的，不要以为自己键盘失灵了。设置完成后可以立刻验证一下：先执行sudo whoami，输入密码后应该输出 root；再执行pwd，确认当前目录是自己的 home 目录。这套流程跑通，说明 Ubuntu 22.04 已经能正常工作了。
我第一次装完就习惯性地先跑了apt update，结果发现 "/etc/apt/sources.list.d/ubuntu.sources" 是 22.04 的新格式源文件，跟以前老的 sources.list 不一样。这个细节我放在后面专门讲，先别急。
3.3 初始化：更新软件包列表和安装基础工具
Ubuntu 刚装完的面貌非常素，没有 GCC、没有 Make、没有 Git，甚至没有 curl。这是因为 Ubuntu 默认镜像只带最基础的系统工具，一切开发环境都需要自己装。首启动后我建议立刻执行：
sudo apt update && sudo apt upgrade -yapt update 负责拉取软件源索引，apt upgrade 会把系统已有的软件包升级到当前源里的最新版本。第一次执行耗时一般比较久，取决于网络速度。升级完成后顺手安装一批开发基础包：
sudo apt install -y build-essential git curl wget net-tools htop unzip zipbuild-essential 里包含 gcc、g++、make 等编译工具链，net-tools 提供 ifconfig 等命令，htop 用于查看进程和内存占用。这套组合是我在 WSL 环境里折腾过很多次后固定下来的基础包，后续无论做 C/C++ 开发、Python 环境、还是容器相关的事情都用得上。
到这里，一个能用的 Ubuntu 22.04 已经有了。但距离"顺手"还差得远，接下来才是把 WSL 调教成日常开发环境的关键部分。
4. 把 Ubuntu 22.04 调教成日用开发环境
4.1 换软件源：一条命令的事，但要小心新格式
Ubuntu 默认的软件源服务器在境外，国内访问速度往往不稳定。这不是什么秘密，也不需要额外解释，反正我用默认源执行 apt update 时，经常卡在几百 KB 每秒的速度，换成境内镜像源之后直接跑满带宽，体验立竿见影。
这里要特别提醒：Ubuntu 22.04 默认的软件源配置格式和以前不一样了。老版本的 Ubuntu 把源写在/etc/apt/sources.list里；22.04 默认使用新的 deb822 格式，源文件改成了/etc/apt/sources.list.d/ubuntu.sources。很多人照着网上教程直接sed -i替换/etc/apt/sources.list，执行完一点反应都没有，就是因为改错文件了。
在动源之前，先备份：
sudo cp /etc/apt/sources.list.d/ubuntu.sources /etc/apt/sources.list.d/ubuntu.sources.bak然后执行替换镜像地址。我用的是阿里云镜像源，命令如下：
sudo sed -i 's@//archive.ubuntu.com@//mirrors.aliyun.com@g; s@//security.ubuntu.com@//mirrors.aliyun.com@g' /etc/apt/sources.list.d/ubuntu.sources保留一份备份文件是多年 Linux 操作养成的习惯，改坏了随时能还原，成本极低。替换完执行sudo apt update，只要没有报错，基本就成功了。
4.2 安装开发工具链：shell、编辑器与服务
基础工具装完以后，还有一个高频操作是把默认的 bash 换成 zsh，配合 Oh My Zsh 使用。这个属于个人偏好，但坦白说，用顺手以后很难回到原始 bash。安装命令也不复杂：
sudo apt install -y zsh sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"如果安装 zsh 的脚本网络不理想，也可以先装好 zsh，手动配一个简单的 .zshrc，再慢慢加插件。我个人实际使用中并没有在这上面花太多心思，默认的 zsh 主题加几条 alias 就够了。真正提升效率的反而是 VSCode 的集成方式，下面单独说。
此外，如果你做 Web 开发或运维，MySQL、Redis、Nginx 这些服务在 WSL 里跑起来异常顺畅，比在 Windows 上装原生版省心太多。比如安装 MySQL 8.0，直接：
sudo apt install -y mysql-server sudo service mysql startWSL 2 下 Ubuntu 22.04 的 systemd 默认是关闭的，这也是一个容易困惑的点，后面会专门提一句怎么开启。总之，任何 Linux 上的开发工具链，在 WSL 里基本能原样跑。
4.3 集成 VSCode：在 WSL 里敲代码的丝滑体验
在 Windows 上装 VSCode，再在 WSL 终端里执行code .，VSCode 会自动打开并连接 WSL 环境。这个功能依赖微软官方的 "WSL" 扩展（Remote - WSL）。装好扩展之后，你在 VSCode 的集成终端里输入命令、运行调试器、访问 Linux 文件系统，感觉就像在 Linux 本机上开发，没有任何隔阂。
这套方案比在 WSL 里装 Linux 版 VSCode 更合理，因为 VSCode 的图形界面跑在 Windows 侧，渲染性能更好；而你的代码、解释器、Git、编译器等全部在 WSL 侧，跟团队协同时候的 Linux 环境完全一致。对比一下：之前我在 Windows 上写 Python 脚本，因为 Windows 和 Linux 的路径分隔符、依赖库版本经常不一致，代码跑到服务器上各种炸。切到 VSCode + WSL 之后，本地环境约等于线上环境，这类问题基本消失了。
如果你需要做 Web 全栈或者云原生，还可以在这个环境里直接跑 Docker。Docker Desktop 支持 WSL 2 后端，安装后 WSL 里的 docker 命令直接可用，容器跑的也是真正的 Linux 内核。
4.4 图形程序怎么跑：Windows 10 的方案
WSL 的优势不局限在命令行。如果你在 Ubuntu 里写代码用到了图形界面，比如 OpenCV 的 GUI、Matplotlib 的绘图窗口，在 Windows 11 上开箱即用 WSLg；但在 Windows 10 上，WSLg 并不默认可用，需要借助 X Server 软件来转发图形显示。
Windows 10 下比较常见的做法是安装 VcXsrv 或 X410。安装 VcXsrv 后启动，再在 WSL 里设置 DISPLAY 环境变量，图形程序就能弹到 Windows 桌面上。这个方案我不想写太细，因为不同版本的 WSL 和 Windows 组合，DISPLAY 的 IP 地址设置会有点差异，而且配置失败率不低。如果你主要是做后端开发或者训练脚本，图形界面需求不强，可以先不折腾这块，等确实需要 GUI 时再针对性解决。
5. 磁盘与资源配置：把 WSL 2 装到 D 盘
5.1 为什么默认装在 C 盘会让你崩溃
WSL 2 发行版的根文件系统默认存放在 C 盘的用户目录下，具体路径大概是C:\Users\<你的用户名>\AppData\Local\Packages\...。这个设计对大多数人没问题，但对那些 C 盘本来就紧张的人来说，问题立刻暴露。
WSL 2 的虚拟磁盘文件（ext4.vhdx）会随着系统使用不断膨胀。一开始只有几个 GB，等你装了 Python 环境、Node、Docker 镜像、CUDA 工具链之后，二三十 GB 轻轻松松。我见过最夸张的情况是有人 C 盘只剩几 GB，跑个 apt upgrade 直接磁盘写满，整个发行版处于半瘫痪状态。所以，如果 C 盘空间比较紧张，强烈建议从一开始就把发行版迁到 D 盘；C 盘富余的朋友也可以先跳过这段，等用出感情了再迁也行。
5.2 把发行版迁移到 D 盘的完整流程
迁移 WSL 2 发行版到 D 盘，官方推荐的是导出 + 注销 + 导入三部曲。整个过程不复杂，但千万注意：注销发行版会删除当前发行版的所有数据，务必先导出备份。
第一步，在 PowerShell 导出当前发行版为一个 tar 文件：
wsl --export Ubuntu-22.04 D:\WSL\backup\ubuntu-22.04.tar记下来这个 tar 文件路径，它是整个发行版的完整快照。第二步，注销原来的发行版：
wsl --unregister Ubuntu-22.04注销完成后，原来 C 盘里的虚拟磁盘就会被删除，空间立刻释放回来。第三步，在 D 盘新建一个目录，并把 tar 文件重新导入进去：
mkdir D:\WSL\Ubuntu2204 wsl --import Ubuntu-22.04 D:\WSL\Ubuntu2204 D:\WSL\backup\ubuntu-22.04.tar --version 2导入完成后，通过wsl -l -v可以看到 Ubuntu-22.04 还叫这个名字，但它的物理文件已经在 D 盘了。到这里一步就遇到了一个经典问题：导入后的默认用户变成了 root，而不是你原来创建的那个普通用户。解决办法是在 WSL 里编辑/etc/wsl.conf：
[user] default=你的用户名把"你的用户名"替换成实际用户名，保存后执行wsl --shutdown重启 WSL，再进入就是普通用户了。如果你嫌自己记不住用户名，也可以用wsl -d Ubuntu-22.04 -u 你的用户名先进入用户环境，再把 wsl.conf 改好。
5.3 用 .wslconfig 限制内存和 CPU
WSL 2 默认会占用 Windows 大量的内存和 CPU 资源，毕竟它本质是一个虚拟机。默认配置下，WSL 2 最多可以占用本机总内存的 50% 或 8GB（取较小值），这个比例对很多人来说太大了。尤其你只是在 WSL 里写写脚本，Windows 后台还跑着浏览器、IDEA、微信，资源很容易被吃掉一大半。
解决办法是在 Windows 用户目录下新建一个.wslconfig文件，写入资源限制配置。文件的完整路径是C:\Users\<你的用户名>\.wslconfig，记事本打开输入：
[wsl2] memory=4GB processors=4 swap=2GB localhostForwarding=true这里 memory 限制 WSL 2 最大内存，processors 限制 CPU 核数，swap 是交换分区大小，localhostForwarding 保持默认 true 即可，它保证 Windows 浏览器直接访问 WSL 里的服务端口。改完配置后必须执行一次wsl --shutdown让配置生效。这个文件是全局配置，对所有 WSL 2 发行版生效。
我推荐先按 4GB 内存、4 核来设置，后期如果跑深度学习或大项目再放宽。内存限制不意味着 WSL 里的程序不能超过 4GB，而是超过后会开始用 swap，相当于一个缓冲，不会把 Windows 本体卡死。
6. 高频报错与排障实录
6.1 启动报错 0x8007019e：WSL2 内核没装
这个错误我印象极深，因为它出现在"看起来一切正常，但就是进不去系统"的时候。具体表现是启动 Ubuntu 时弹出一段英文错误，后面跟着 0x8007019e。这个错误码的含义非常明确：WSL 2 内核更新包没有安装。
解决办法也很直接，回到前面 2.3 节提到的，去微软官网下载 wsl_update_x64.msi 并安装，重启 WSL 后问题就消失了。如果你忘了自己的系统是 x64 还是 ARM64，可以先在 PowerShell 里跑$env:PROCESSOR_ARCHITECTURE确认一下，别下载错了架构。
6.2 报错 wsl/installdistro/service/registerdistro/createvm/hcs 类错误：底层组件问题
网上经常看到这类路径比较长的错误，核心围绕 createvm、hcs 这些关键词。它通常说明 Windows 的虚拟化底层服务（Hyper-V Host Compute Service）出了问题，或者虚拟化功能没有完整开启。
排查步骤如下：先在 PowerShell（管理员）里执行net stop vmcompute然后net start vmcompute重启这个服务。如果还是报错，检查自己是否真的启用了"虚拟机平台"功能，BIOS 里的虚拟化开关是否打开。还有一个容易忽略的点是，在 Windows 10 上启用 WSL 2 需要 Hyper-V 相关组件，但部分品牌机的"内核隔离"或"基于虚拟化的安全"（VBS）策略会和 WSL 2 冲突，可以尝试关闭 Windows 安全中心里的内核隔离功能再试。
如果问题仍然存在，执行两段修复命令：
sfc /scannow DISM.exe /Online /Cleanup-Image /RestoreHealthsfc /scannow扫描系统文件完整性，DISM 修复系统映像组件。这两条命令在 Windows 遇到各种疑难杂症时都很值得优先执行，虽然耗时可能十几分钟，但真能解决不少隐藏问题。
6.3 系统更新错误 0x8000ffff 与组件存储损坏
0x8000ffff 代表的含义比较宽泛，常见于 Windows Update 或应用商店相关操作。我第一次遇到是在商店里搜索安装 Ubuntu 时，商店一直弹错误，提示就是 0x8000ffff。当时我以为是商店挂了，后来发现商店组件状态有问题。
解决办法是执行wsreset.exe重置商店缓存，再用管理员 PowerShell 跑sfc /scannow和 DISM 修复。如果这些都救不了，还可以尝试把 Windows 更新组件相关服务重启一遍。说实话，这种错误在 Windows 10 上偶尔会遇到，心态放平，先按通用修复流程走，大概率能解决。
6.4 apt 命令权限与 sudoers 问题
Ubuntu 里用 apt 安装软件，必须加上 sudo 前缀，否则会提示权限不足。这个是好习惯，也是安全设计的一部分。但也有一种情况：你用了 WSL 发行版导入的方式，默认用户变成了 root，之后执行sudo反而提示user is not in the sudoers file，因为 root 用户不需要 sudo。
解决办法是用发行版的 Windows 可执行文件设置默认用户，例如在 PowerShell 中执行：
ubuntu2204.exe config --default-user 你的用户名或者通过 WSL 命令以 root 身份进入，修改/etc/sudoers或在/etc/sudoers.d/下新建文件，把用户加进 sudo 组。我自己推荐后者，因为更接近 Linux 原生操作习惯。
6.5 误删或注销后重新注册发行版
如果你在迁移过程中不小心执行了wsl --unregister，那系统提示的"磁盘空间已释放"不是开玩笑的，C 盘里的整个发行版都会被清掉。如果你没有提前导出备份，这个操作没法撤销，唯一的安慰是用户自己的个人文件在/mnt/c那边可以保留，但 Linux 环境里的配置、已安装软件、数据库内容全部丢失。
所以迁移 D 盘的完整流程里，我反复强调导出备份这一步。如果你还保留了 tar 备份，重新导入即可恢复原本的环境；如果没有，只能重新走一遍商店安装流程。我个人的习惯是：每次大版本升级、迁移、清理前，都先wsl --export一份存到 D 盘备份目录，文件名带日期，比如ubuntu-22.04-2024-xx-xx.tar。这个习惯救过我至少两次，成本才几十秒，收益却很大。
最后再分享一点实操心得
用 WSL 2 这段时间，我最大的感受是它终于把 Windows 和 Linux 两套生态的割裂感消解得差不多了。日常开发里我不用再为"Windows 上没有 Linux 命令"而抓狂，也不用为了一个 binwalk 工具就去装虚拟机。包管理、文件系统、终端体验这些细节，WSL 2 都已经能提供足够好的替代方案。
如果你准备往下走，我建议继续研究三个方面：第一个是 systemd 的启用，WSL 2 较新版本已经支持在/etc/wsl.conf里配置systemd=true，让服务管理逻辑跟原生 Ubuntu 完全一致；第二个是 Docker 的后端集成，Docker Desktop 搭配 WSL 2 后，容器化开发会顺畅很多；第三个是机器学习方向，NVIDIA 显卡配合 WSL 2 跑 CUDA 已经有很成熟的方案，Windows 下做深度学习训练不再像过去那么折腾了。WSL 这套东西看着简单，实际上踩着坑跑通以后，工作效率的提升是实实在在的。
