WSL 2 上手指南
在 Windows 上进行代码开发、运行测试或学习机器学习，过去往往需要借助虚拟机才能在 Linux 环境中完成
WSL 2 使用户能够在 Windows 中迅速切换至 Linux：文件系统互通，CUDA 直通，空闲时几乎不占用资源
本文将介绍其安装与基本配置方法
准备工作
开始安装前，需确认以下两项前置条件，否则后续步骤可能受阻。
Windows 版本：按 Win+R 调出运行窗口，输入 winver 后回车，即可查看当前系统版本号。Windows 10 需为 2004 版（Build 19041）或更高，Windows 11 全部版本均可支持。若版本过低，请先通过 Windows Update 升级。
虚拟化已开启：打开任务管理器（Ctrl+Shift+Esc），切换至”性能”标签页,CPU 一栏下方会显示”虚拟化：已启用”或”已禁用”。
若显示为”已禁用”,需重启进入 BIOS 启用相关选项(Intel 平台称为 VT-x,AMD 平台称为 AMD-V 或 SVM)。各品牌主板进入 BIOS 的方式不同,请根据自身主板型号自行查询。
安装
以管理员身份打开 PowerShell（在开始菜单上右键，选择”终端（管理员）”），执行以下命令：
1 | wsl --install |
即可完成。该命令会自动启用所需的 Windows 功能、下载 WSL 主程序，并安装默认的 Ubuntu 发行版。
安装过程的输出大致如下：
1 | 正在下载: 适用于 Linux 的 Windows 子系统 2.6.3 |
过程中出现的 localhost 代理相关警告暂可忽略，后续”配置 .wslconfig”一节将统一处理。
安装完成后，Ubuntu 会自动启动，并提示创建 Linux 用户名与密码。此处需注意两点：
- 此处的用户名与密码仅用于 Linux 子系统内部，与 Windows 登录账号无关。
- 输入密码时屏幕不会回显星号或圆点，属正常现象，请按正常方式输入，无需误以为键盘失灵。
安装特定的 Linux 发行版
如不希望使用 Ubuntu，可先查看可用的发行版清单：
1 | wsl --list --online |
通常会列出多种可选的发行版本：
1 | NAME FRIENDLY NAME |
随后通过参数指定所需的发行版本即可：
1 | wsl --install -d Debian |
验证
安装完成后，可在 PowerShell 中进行验证：
1 | wsl -l -v |
输出如下内容即表示安装成功：
1 | NAME STATE VERSION |
当 State 显示为 Running、Version 显示为 2 时，即表明 WSL 已正确安装。行首的星号表示该实例为默认实例。
配置 .wslconfig
.wslconfig 是 WSL 2 虚拟机本身的配置文件，用于管理内存、CPU、网络等全局参数。该文件仅在虚拟机启动时读取一次，因此修改后需执行 wsl --shutdown 关闭虚拟机并重新启动，新配置方可生效。
该配置文件位于：
1 | C:\Users\<你的Windows用户名>\.wslconfig |
若文件不存在，需手动创建。文件名以英文句点开头，且没有任何扩展名。需特别注意：Windows 资源管理器默认隐藏文件扩展名，看似名为 .wslconfig 的文件，实际可能是 .wslconfig.txt。建议事先在资源管理器中勾选”文件扩展名”显示选项，以便确认文件名正确。
推荐配置
将以下内容写入配置文件：
1 | [wsl2] |
四项配置的具体作用如下：
networkingMode=mirrored：开启镜像网络模式，使 WSL 直接共用 Windows 的网络栈，localhost在两端指向同一地址。例如 Windows 上运行的 Clash 监听127.0.0.1:7890时，WSL 中可直接访问。dnsTunneling=true：DNS 请求经由 Windows 解析，在连接企业 VPN 时可避免大部分 DNS 解析问题。firewall=true：将 WSL 流量纳入 Windows Defender 防火墙的管控范围。autoProxy=true：自动将 Windows 的代理设置同步至 WSL。文章前述安装阶段出现的代理相关警告，正是由该项配置消除的。
配置完成后，回到 PowerShell，执行 wsl --shutdown 使新配置生效。
常用命令
1 | wsl -l -v # 查看所有实例及其状态 |
使用 wsl --unregister 时务必谨慎。该命令会永久删除整个实例及其全部数据，且不进入回收站，无法恢复。
实用工具与故障排查
充分发挥 WSL 价值的关键工具，是 VS Code 的 Remote - WSL 扩展。安装该扩展后，在 WSL 中切换至项目目录并执行 code .，Windows 端的 VS Code 会自动连接至 WSL 进行编辑——IDE 运行于 Windows，文件存储与编译过程则全部位于 Linux，几乎不存在延迟。这是 WSL 最具代表性的使用体验之一。
若使用过程中出现异常，可通过以下方式进行排查：
- 在 WSL 中执行
dmesg，查看内核日志。 - 在 PowerShell 中执行
wsl --status，查看整体运行状态。
附录
附录 A：WSL 的演进
此处简要介绍 WSL 能够保持轻量的技术背景，供有兴趣的读者参考。
微软于 2016 年首次推出 WSL（现称 WSL 1），其核心思路为系统调用翻译：在 Windows 内核中实现一个兼容层，将 Linux 程序发出的 open、fork、read 等系统调用实时翻译为 Windows NT 内核调用。该方案启动迅速，与 Windows 的互通性也较为理想，但兼容性存在明显短板——依赖 cgroups、namespaces 的工具（如 Docker）无法运行，文件 I/O 性能亦较差。
2019 年，微软放弃了系统调用翻译方案，转而采用完全不同的架构：在 Windows 中运行一台经过精简的 Hyper-V 虚拟机，其中安装由微软自行维护、源码开源的真实 Linux 内核。自此，WSL 中运行的是真正意义上的 Linux，系统调用完全兼容，Docker、systemd 及各类内核特性均可正常使用。
截至 2026 年，WSL 已从 Windows 系统组件中独立出来，成为一个开源项目，可通过 Microsoft Store 独立安装与更新，迭代速度较以往显著提升。本文全篇所述均默认指 WSL 2。
附录 B：不适用 WSL 的场景
WSL 并非适用于所有场景。以下几类情形仍建议使用传统虚拟机：
- 需要使用完整的 Linux 桌面环境（如 GNOME、KDE）。WSL 虽支持运行 GUI 程序，但并不适合作为主力桌面环境使用。
- 进行内核开发，或对安全沙箱有严格要求。WSL 使用的是微软维护与发布的定制内核，用户无法自由替换。
- 运行与 Windows 网络栈高度耦合、且经常需要修改防火墙规则的工具——此类工具与 WSL 容易产生冲突。