1. 为什么我把 WSL 当作日常开发主力：能力边界与适用场景
如果你是一个长期在 Windows 上工作、又离不开 Linux 命令行环境的开发者，那么 WSL（Windows Subsystem for Linux，Windows 的 Linux 子系统）几乎是最顺手的入场券。它不需要重启到另一个系统，不需要一份完整的虚拟机镜像，也不需要买一台单独的 Linux 机器，在现有 Windows 系统里跑起一个真正的 Ubuntu，然后正常用 VS Code、Docker、PyTorch、binwalk 这些工具。很多人对 WSL 的认知还停留在"在 Windows 里开个 Linux 窗口"，实际上它直接改变了我的日常开发方式。
我在这篇文章里想讲的，不只是"怎么装 WSL"，而是把这两年从安装、换路径、配 CUDA、跑 Docker、碰到的各种报错，到最终把 WSL 变成主力开发环境的完整经验串一遍。内容既覆盖从 Win10/Win11 上的一键安装和离线安装，也覆盖了 VS Code 联动、PyTorch 环境搭建、网络模式切换、常见报错排查这些高频需求。适合完全没接触过 WSL 的新手，也适合已经装好但被各种"wsl needs updating""无法与服务器建立连接"之类问题卡住的人。
1.1 WSL1 和 WSL2 的区别到底在哪一层
这可能是入门时最容易被绕晕的一点。WSL1 不是虚拟机，而是一个系统调用翻译层，它把 Linux 程序发出来的系统调用直接转译成 Windows 系统调用。优点是启动极快、共享 Windows 网络和文件系统很顺畅，但坏处也很明显：不是所有 Linux 程序都能被正确翻译，尤其碰上需要内核模块、复杂 ioctl 或者和硬件强相关的操作时，兼容性就露馅了。
WSL2 则是微软内置在 Windows 里的轻量虚拟机，运行的是一个真正经过微软定制编译的 Linux 内核。它和 VMware/VirtualBox 这类传统虚拟机的本质区别在于：WSL2 的虚拟机管理器（Hyper-V 底层）针对 WSL 做了大量优化，启动速度仍然很快，内存分配是动态的，由宿主机按需分配再回收。对普通开发者来说，WSL2 的兼容性更接近一台真实服务器，比如跑 Docker 要的就是 Linux 内核，在 WSL1 下几乎转不起来，WSL2 下则和原生 Linux 几乎没区别。
有一个细节值得提：哪怕在 WSL2 下，跨文件系统的性能依然有差异。Linux 程序访问自身 ext4 文件系统（也就是 WSL 发行版内部的目录）速度接近原生，但如果去访问/mnt/c下的 Windows 文件，因为要经过 9p 协议转换，小文件读写会明显慢。所以后面我专门把"项目文件放哪里"单独列了一节，这是很多人用了一段时间才发现的坑。
1.2 虚拟机、双系统、WSL2 三者怎么选
先给一张对比表，这是我经常拿来给同事解释的版本：
| 方案 | 启动速度 | 资源占用 | Linux 兼容性 | 与 Windows 文件互通 | 适用场景 |
|---|---|---|---|---|---|
| 双系统 | 慢（需重启） | 独占整机 | 最高 | 不方便 | 需要完整桌面、显卡直通、原生性能 |
| 传统虚拟机 | 中等 | 固定分配 | 高 | 一般 | 需要完整 GUI、快照、隔离环境 |
| WSL2 | 秒级 | 动态内存、按需分配 | 高 | 非常方便 | 日常命令行开发、Docker、AI 环境 |
有人会问："那虚拟机里的 Ubuntu 和 WSL 里的 Ubuntu 到底有什么不同？" 本质上跑的都是同一个 Linux 用户态发行版，apt、bash、Python 这些完全一样。差别在几个地方：虚拟机有完整内核和完整虚拟硬件，你可以随便装桌面环境、随意设置网卡，甚至可以跑一个完整 KVM；WSL2 内核由微软裁剪和管理，你不能随便换内核（除非自己编译放进去），网络模型默认也更像容器而非真机。另一个常被忽略的点是，虚拟机在宿主机"无活动"时依然会按配置占用固定内存和 CPU，而 WSL2 的空闲回收机制做得很激进，发行版不开窗口不跑进程时，宿主机的内存和 CPU 负担基本趋近于零，不会像传统虚拟机那样空运行白白耗电。
1.3 哪些场景适合 WSL，哪些场景不建议用
我比较推荐把 WSL 用在命令行开发为主的工作流里：写 Python/Node/Rust 脚本、编译 C/C++ 项目、操作 Docker 容器、跑数据处理、还有做固件分析（比如binwalk）这类典型 Linux 工具链。深度学习方向也合适，WSL2 配合 NVIDIA 显卡做 CUDA 加速在官方支持下已经很稳定，PyTorch 环境搭建的体验和 Linux 服务器几乎一致。
对以下场景我反而建议慎用：需要完整桌面环境（GNOME/KDE 全功能桌面）、需要直接操作 USB 设备做串口抓包或者硬件烧录、需要加载非微软认证内核模块（比如某些特殊驱动）。这些需求不是"不能做"，而是会花费大量额外精力去适配，不如直接开个虚拟机或者用真实物理机更省事。简单说，WSL 是"Windows 里的高效 Linux 命令行环境"，不是"Windows 里的完整 Linux 桌面主机"。
2. 从零到跑通：Win10/Win11 安装 WSL 的完整流程
2.1 装之前必须确认的三件事
很多人装 WSL 失败，不是命令打错，而是前置条件没满足。第一，操作系统版本。Win10 2004 及以上、Win11 全系列支持官方一键安装；更老的 Win10 版本不是不能装，但会麻烦不少，还容易遇到"wsl needs updating"之类的提示。第二，BIOS 里的虚拟化必须开启。Intel 的 VT-x 和 AMD 的 SVM 都要打开，否则后面启动 WSL2 会直接报"此计算机上未启用虚拟化"。第三，Windows 可选功能里要启用"虚拟机平台"。Win10 下如果之前没开过 Hyper-V 相关功能，建议先手动把"适用于 Linux 的 Windows 子系统"和"虚拟机平台"两个可选功能都勾上。
怎么快速确认虚拟化开没开？打开任务管理器，切到"性能"标签，看 CPU 那一页里"虚拟化"状态是不是"已启用"。如果显示"已禁用"，就得重启进 BIOS 设置。这一步我见过太多人忽略，结果在软件层面折腾半天，最后发现是 BIOS 没开。
2.2 一行命令安装 wsl --install，以及指定 Ubuntu 版本
在管理员权限的 PowerShell 或终端里执行：
wsl --install这条命令会做四件事：启用必要的 Windows 功能、下载并安装 WSL2 内核、将默认版本设为 WSL2、安装默认的 Ubuntu 发行版。如果不想用默认版本，可以先用wsl --list --online查看当前支持的所有发行版，然后指定：
wsl --install -d Ubuntu-24.04执行完会进入 Ubuntu 的初始化过程，让你设置一个独立的 Linux 用户名和密码。注意这个账号是 Linux 发行版自己的账号，跟 Windows 登录账号不是一回事，后面通过 sudo 操作时用的是它。
这里多说一句：很多教程让你去 Microsoft Store 手动搜 Ubuntu 再点安装，其实在大多数情况下一键命令更可靠。Store 版本的问题是它会单独作为 MSIX 应用安装，某些精简系统或企业策略下容易被限制；而命令行方式安装的 WSL 发行版在管理和路径迁移上更直接。
2.3 国内网络环境下安装被卡住：怎么回事、怎么处理
热搜里"国内无法 wsl 安装 ubuntu""wsl --install -d ubuntu 加速""wsl --update --web-download 太慢了"这类问题非常集中。坦白说，WSL 相关的下载走的是微软官方渠道，而微软的 CDN 在国内的连通性受网络环境影响较大，表现就是卡在下载阶段，或者报"无法与服务器建立连接"。
我的处理原则是：优先用官方机制，不做任何来路不明的"加速"。具体做法是错峰重试：换个网络环境（比如从 WiFi 切到手机热点），或者过一段时间再执行wsl --install，很多情况下是临时连接问题，重试就能过。如果一直卡住，可以转用离线安装方式，后面 5.4 节会详细讲，思路就是把发行版 rootfs 用wsl --import方式导入，完全绕开在线下载环节。更新 WSL 本身如果觉得wsl --update --web-download慢，也可以直接访问微软官方的 WSL 发布页面下载安装包手动更新，同样是官方渠道，只是多了个"自己点下载"的操作。
2.4 把发行版装到 D 盘：路径迁移方法
默认情况下 WSL 发行版全放在 C 盘，而且占用不小（一个 Ubuntu 跑一阵子，几十 GB 很正常）。如果你 C 盘紧张，热搜里"wsl 安装到 d 盘""win10 更改安装 wsl 路径"就是解法。最稳的迁移方式不是改注册表，而是用官方命令导出再导入。
步骤很清晰：
wsl --list --verbose先看发行版名称和状态。然后导出为 tar 文件：
wsl --export Ubuntu D:\wsl-backup\ubuntu.tar注销掉原来的发行版（这会清空原数据，所以上一步的导出必须成功）：
wsl --unregister Ubuntu最后导入到 D 盘指定位置：
wsl --import Ubuntu D:\WSL\Ubuntu D:\wsl-backup\ubuntu.tar --version 2注意一点：wsl --import导入的发行版，默认登录用户是 root，而不是你原来设置的普通用户。需要自己在 Ubuntu 里修改默认用户。网上有一种方法是直接把默认用户配到/etc/wsl.conf的[user]段：
[user] default=你的用户名然后在 PowerShell 里执行wsl --shutdown再重新进入。这个方法不依赖额外工具，实测有效。迁移完成后，原 C 盘空间会释放，发行版数据全部落在 D 盘。备份文件如果确认不需要了，也可以删掉。
2.5 老版本 Windows 和 Windows Server 2022 的特殊处理
如果你的系统提示"wsl needs updating"或者"your version of windows subsystem for linux is too old"，说明当前系统的 WSL 组件版本太旧。常见于老 Win10 或者长期没更新的系统。处理方式就是执行：
wsl --update这条命令会拉取新版 WSL 组件。如果系统本身太老连--update都不支持，那就得先把 Windows 更新到至少 2004 版本，再走标准安装流程。
Windows Server 2022 离线部署 WSL 是另一个独立场景，多见于内网服务器环境。思路是：在能联网的机器上把 WSL 安装包、内核 MSI、发行版 rootfs 全部下载好，然后拷到目标服务器上，通过命令手动启用功能和安装包，最后用wsl --import导入发行版。容器场景下还要确认 Windows Containers 相关功能的状态，避免 Docker Desktop 或 containerd 后端和 WSL 冲突。具体命令和在线安装类似，只是把"在线拉取"换成了"本地文件安装"，这节只标记一个重点：内网环境一定要先备齐wsl install所需的安装包文件以及对应发行版原版镜像，缺一个都会在部署阶段卡住。
3. 日常开发环境搭建：从终端到 IDE
3.1 在 VSCode 中使用 WSL：Remote-WSL 的正确打开方式
装好 WSL 之后，第一件事就是把 IDE 接进来。VS Code+Remote-WSL插件是目前体验最顺的方案。安装好插件后，在 WSL 终端里进入任意项目目录，执行：
code .VS Code 会自动感知到当前是 WSL 环境，在 Windows 侧打开编辑器窗口，同时在 WSL 内部启动一个 VS Code Server。效果是：你看到的 UI 是 Windows 上的 VS Code，但终端、调试器、语言服务、文件读写全都在 Linux 环境里运行。这意味着你在 Linux 装的那些 Python 包、Node 模块、编译器，IDE 都能直接用，不需要在 Windows 侧再配一遍环境。
有几个细节值得注意：第一次code .会在线下载 VS Code Server，如果网络不佳可能卡住，多试几次或者确认官方下载源可达即可；插件要区分"本地安装（UI 扩展）"和"WSL 内安装（工作区扩展）"，比如 Python、ESLint 这类要装在 WSL 侧才能正确解析项目；远程资源管理器视图里能看到当前 WSL 发行版的入口，随时切换。整体来说，Remote-WSL 之后我已经很少再开传统虚拟机做开发了。
3.2 Ubuntu 基础配置、软件源和文件路径互通
Ubuntu 装好后，一般第一件事是更新软件源。由于官方源在部分网络环境下速度不佳，建议先把源切换成国内高校或云厂商的镜像源。具体做法是把/etc/apt/sources.list（Ubuntu 24.04 以后可能是/etc/apt/sources.list.d/ubuntu.sources）里的源地址替换为镜像站地址，然后执行：
sudo apt update && sudo apt upgrade -y再装基础工具链：
sudo apt install build-essential git curl wget unzip文件互通是 WSL 的一大优势。从 WSL 里访问 Windows 文件直接走/mnt/c，比如你的项目在C:\work\demo，在 WSL 里就是/mnt/c/work/demo；反过来从 Windows 访问 WSL 文件，可以在资源管理器地址栏输入\\wsl$\Ubuntu或者\\wsl.localhost\Ubuntu，直接以 UNC 路径形式访问 Linux 家目录。另外我强烈建议：日常项目放在 Linux 家目录（/home/用户名/...）而不是/mnt/c下，因为同一文件系统内读写性能要好得多，npm install、git status这类小文件密集操作差距尤其明显。
3.3 PyTorch 环境搭建：驱动、CUDA、虚拟环境的正确顺序
"WSL 安装 CUDA""PyTorch 环境搭建 WSL"是出现频率很高的搜索词。这里的顺序如果搞错，后面很容易出现torch.cuda.is_available()返回 False 的情况。
先说结论：GPU 驱动装 Windows 侧，WSL 内部不需要装显卡驱动，也不需要单独装完整的 CUDA Toolkit。步骤是：
- 在 Windows 侧安装最新版 NVIDIA 驱动（必须是支持 WSL CUDA 的版本，近几年的驱动基本都支持）。
- 进入 WSL，安装 miniconda 或 Anaconda，创建 Python 虚拟环境。
pip install torch，PyTorch 的官方 wheel 自带 CUDA runtime，不需要自己装 CUDA toolkit。
验证是否成功：
python -c "import torch; print(torch.cuda.is_available())"如果返回 True，基本就成了。常见问题有两个：一是驱动过老，WSL 里nvidia-smi都跑不起来，解决方法是去 NVIDIA 官网更新 Windows 驱动；二是直接装系统级 Python 而不是虚拟环境，导致包互相污染，建议一律用 conda 或 venv 隔离。另外，WSL 里如果要跑 GPU 版本的 TensorFlow 或者 PyTorch，记得在 Windows 的"可选功能"里确认"虚拟机平台"处于开启状态，否则 GPU 直通不生效。
3.4 binwalk 这类命令行工具：WSL 里的典型用法
热搜词里"wsl 使用 binwalk"让我很感慨，因为做固件分析、CTF 逆向的人很多都用 WSL 当主力。binwalk这类工具在 Windows 原生环境基本没法愉快使用，依赖的 Python 库和 Linux 文件系统特性在 Windows 下各种水土不服，而 WSL 里直接：
sudo apt install binwalk就能把整条固件分析工具链跑起来。解包固件文件时，文件放哪影响很大：如果固件在 Windows 磁盘上，要在 WSL 里长时间解包大量小文件，强烈建议先把文件复制到 WSL 家目录再操作，否则一堆小文件经/mnt/c的跨系统访问会慢得让你怀疑人生。
另一个常用的场景是结合文件系统操作：在 WSL 里可以直接挂载和检查 ext4 镜像、squashfs 镜像，而这些在 Windows 原生环境几乎不可用。配合\\wsl$路径，Windows 侧的图形工具（比如 010 Editor、HxD）也能直接打开 WSL 里生成的分析结果文件，两边配合非常顺滑。
4. 进阶玩法：Docker、Claude Code 与 WSL 3.0 新变化
4.1 Docker Desktop 与 WSL2 的联动，以及"docker 更新后运行不了"的排查
Docker Desktop 在 Windows 上的最佳实践就是选用 WSL2 后端。安装 Docker Desktop 时它会自动识别 WSL 发行版，并在设置里允许你把"Use the WSL 2 based engine"打开，同时可以选择哪些发行版集成 docker 命令。设置完成后，WSL Ubuntu 里直接docker ps就能用，不需要在 Linux 内部再装 Docker Engine，容器的实际运行环境是 Docker Desktop 管理的 WSL2 专用发行版。
很多人在 Docker Desktop 更新之后发现"运行不了 WSL"或者容器起不来，我排查这类问题的固定路径是：
- 先看 WSL 本身是否正常：
wsl --status，如果提示版本过旧，先wsl --update。 - 打开 Docker Desktop 的 Settings，到 Resources 的 WSL Integration 页签，确认目标发行版的集成开关是打开的。
- 在 PowerShell 执行
wsl --shutdown，再重启 Docker Desktop 和 WSL 发行版，让两个组件重新建立连接。 - 如果还不行，检查 Docker Desktop 是否安装了新版本后要求 WSL 版本升级，看它的提示信息直接更新即可。
4.2 NAT 模式与镜像模式：什么时候该改网络配置
WSL2 默认网络模式是 NAT，也就是 WSL 内部有自己的虚拟网卡，通过 NAT 访问外网，Windows 宿主通过localhost转发可以访问 WSL 里启动的服务。对大多数本地开发来说这个模式够用，localhost:8080直达 WSL 里的服务。
但如果你需要在局域网内让其他设备访问 WSL 里的服务，或者 WSL 程序需要和 Windows 同一网络环境交互，NAT 的"虚拟网卡 + 端口转发"逻辑就有点别扭。WSL 2.0 之后提供了镜像网络模式（mirrored mode），在用户目录下创建.wslconfig：
[wsl2] networkingMode=mirrored开启后重启 WSL（wsl --shutdown），WSL 会共享 Windows 的网络接口，IPv4/IPv6 地址一致，防火墙规则也一致。实测在镜像模式下，跑在本机的 Web 服务、SSH 服务的暴露行为更像一台真实插入局域网的机器，省去了端口映射的烦恼。注意这是一个全局 WSL 配置，改完对所有发行版生效，如果你主要做本地开发，没必要默认开启，按需切换即可。
4.3 wsl --update 与 WSL 3.0 的新变化
很多人搜"wsl 3.0""wsl 3.01"，其实是看到了一些新版本号和更新提示。WSL 2.x 时代开始，WSL 组件从 Windows 系统组件中分离出来，变成了 Microsoft Store 上可以独立分发的应用，所以有了wsl --update --web-download这类更新命令。站在 2025 年的角度，WSL 的更新节奏明显加快，新版本带来的实质变化主要是：systemd 默认集成（发行版里systemctl命令直接可用）、镜像网络模式、自定义内核支持，以及更稳定的跨文件系统性能。
微软已经把 WSL 的下一代版本提上了日程，方向是改变当前的轻量虚拟机实现方式，让 Linux 环境启动得更快、资源占用更低，同时保留现有发行版兼容性。对普通用户来说，不需要追着新版跑，只要记住一件事：如果遇到wsl: 检测到 localhost 代理配置...之类的提示，或者官方提示"你的 WSL 版本太旧"，就执行wsl --update把组件更新到最新，很多疑难杂症会直接消失。
4.4 在 WSL 里安装和使用 Claude Code 的体验
热搜里"windows wsl 安装 claude code"说明 AI 编程工具在 WSL 下的需求确实不小。Claude Code这类命令行 AI 编程助手本质是 Node.js 应用，在 WSL 环境安装和 Linux 上基本一致：先确保 Node.js 环境，然后用官方推荐的安装方式装好，在 WSL 终端里进入项目目录运行即可。
为什么建议在 WSL 里跑而不是 Windows 终端里？因为多数项目代码、构建工具链都在 Linux 环境，AI 助手读取文件、执行命令需要和项目环境一致。在 WSL 里运行它，才能让它正确调用gcc、python、git这些工具；如果项目依赖 Docker，那 WSL 环境更是唯一合理的运行位置。有个细节：WSL 里的终端需要能正常访问服务端点，如果出现网络相关报错，先检查 Windows 侧防火墙或网络策略，不要一上来就归咎于 WSL 本身。
5. 报错排查链路：把常见错误按现象分类整理
5.1 安装阶段的报错集合
"无法与服务器建立连接"。这个报错多半发生在wsl --install -d Ubuntu下载发行版阶段。原因集中在线路拥挤或官方源暂时不可达。我的建议是按顺序尝试：直接重试；换一个时段；确认防火墙没有拦截 wsl 服务的域名；最后考虑离线安装。不要从不明确的第三方渠道下载所谓"修复工具"。
"wsl needs updating"。Windows 自带的老版本 WSL 组件在运行新发行版时会给出这个提示。执行wsl --update更新 WSL 本体即可。
"错误 14098"。这个报错我在老系统上遇到过，通常和 WSL 服务状态异常、或旧版 WSL 组件残留有关。处理步骤：管理员身份运行 PowerShell，执行net stop LxssManager和net start LxssManager重启 WSL 服务；不行就重启系统；再不行就检查系统更新和 WSL 组件版本。
"无法获取分支"。多是写错了发行版名称，或者源分支信息没拉下来。用wsl --list --online查官方列表里的准确名称，再重新执行安装命令。
5.2 启动阶段：WSL2 无法启动和未启用虚拟化
热搜里"运行 wsl --install -d ubuntu-24.04 时，报错 wsl2 无法启动，因为此计算机上未启用虚拟化"是典型场景。虽然安装流程会自动启用 Windows 功能，但 BIOS 层的虚拟化开关它管不了。排查顺序：
- 任务管理器确认 CPU 虚拟化是否"已启用"，如果是"已禁用"，进 BIOS 开 VT-x 或 SVM。
- Windows 可选功能里确认"虚拟机平台"已勾选，没勾就勾上并重启。
- 检查是否和其他虚拟化软件冲突。某些旧版本虚拟机软件未正确卸载时会干扰 Hyper-V 层，把三方虚拟化软件彻底移除后重试。
- 最后执行
wsl --update更新内核，再次wsl --shutdown后重新进入。
5.3 运行阶段：Docker 集成失效和 WSL 里的小物件
运行阶段最常见的是 Docker Desktop 更新后 WSL 发行版里docker命令突然失效，原因是 WSL 集成开关被重置了。按 4.1 的路径重建集成即可。整体思路就一句话：WSL 本身没问题，是 Docker Desktop 和 WSL 之间的"钩子"掉了，重挂一次的事。
热搜里还有"wsl 安装了 hermes"，多半是在 WSL 里跑 Node.js 相关的 Hermes 引擎，比如 React Native 打包时的 JavaScript 引擎。这本身不是错误，是环境提示，不影响 WSL 使用。如果看到相关信息感到困惑，检查一下是否在跑 Metro 或 React Native 相关构建即可。
5.4 离线安装 Ubuntu 与标准卸载重置
离线安装适用于内网、无外网或网络极不稳定的场景。整体思路是：准备 Ubuntu 的 rootfs 镜像（比如官方 WSL 发行版的 tar 包），然后：
wsl --import Ubuntu-DIY D:\WSL\Ubuntu-DIY D:\downloads\ubuntu.tar --version 2导入完成即可使用，不需要在线下载。rootfs 可以来自微软官方渠道的离线包、也可以是 Docker 镜像导出的文件系统。具体到"怎么将 CentOS ISO 制作成 WSL 安装包"，原理上是先把 ISO 中的运行时文件系统整理成一个标准的 rootfs 目录结构，封装成 tar，再用wsl --import导入。但 CentOS 官方已经不提供 WSL 发行版包，自制过程比较折腾，建议日常直接使用官方支持列表里的发行版，省心得多。
卸载一个发行版用：
wsl --unregister Ubuntu这会删除该发行版的全部数据。如果你只是想重置环境，标准做法是先wsl --export备份，再 unregister，然后重新 import。注意 unregister 是删数据，不是停用，执行前务必确认数据已经备份。
5.5 WSL 和 Docker 共存时的网络与配额问题
还有一个容易踩的坑是 WSL 里跑 Docker 容器时发现端口不通。如果开的是 NAT 模式，容器端口的本地转发一般没问题，但局域网其他机器访问不了。镜像模式开启能缓解，但需要确认 Windows 防火墙没有拦截。另外，WSL2 的内存和 CPU 配额默认是宿主机一半，如果你跑大 Docker 容器发现卡顿，可以在.wslconfig里调整：
[wsl2] memory=8GB processors=4改完wsl --shutdown再重启生效。这类配置我建议一次只改一个参数，验证没问题再动下一个，避免多个参数一起调整后反而搞不清是谁的功劳。
6. 我绕了不少弯才明白的几个细节
说几个不是"教程里会写"、但实际用下来很重要的点。
第一个是文件存放位置的教训。我刚用 WSL 时图方便，把项目直接放在 Windows 的 D 盘，然后从 WSL 用/mnt/d访问，结果npm install一次要好几分钟，而同样的项目放到 WSL 家目录后只要几十秒。跨文件系统的小文件 I/O 性能差距就是这么大。所以我的工作流变成了：代码存在 Linux 家目录，通过 VS Code 的 Remote-WSL 访问，必要时再同步到 Windows 侧。
第二个是不要随意修改.wslconfig里的默认参数。很多人看到网上说"改资源限制、换网络模式"，就直接全抄一遍，结果 WSL 跑不起来了。我的建议是，没有明确问题就不要改配置；碰到问题了，一次改一个参数，并且用wsl --shutdown让配置生效，而不是直接重启终端。记一笔：.wslconfig的修改只影响 WSL2 发行版，不影响 WSL1。
第三个是 WSL 的systemd支持早已默认开启。如果你搜到老教程让你手动在/etc/wsl.conf里加systemd=true，在新版本里已经不需要了，直接systemctl status就能用。新旧教程信息混杂很容易让新手迷路，优先参考官方文档和近半年的文章，老教程里的操作可能反而帮倒忙。
第四个是关于"无活动时宿主机会不会空运行"的问题。WSL2 的轻量虚拟机在发行版没有进程时会被挂起，内存自动归还宿主机，CPU 占用归零。你不会看到一个 4GB 的虚拟机进程一直占着内存不放，这也是我敢在低配笔记本上同时开着 WSL 和 Windows 工具链的原因。真正占资源的是你跑起来的容器和编译任务，不是 WSL 本身。
如果你现在还在 Windows 环境里挣扎着配置各种 GNU 工具链，或者被 Docker Desktop 的报错搞得头疼，不妨花半小时把 WSL 装好，按照这篇文章把环境一步步搭起来。实用、轻量、和 Windows 黏合度高，这可能是我这些年用过的、性价比最高的开发环境之一。
