对于需要用Windows办公的很多工程师而言，Windows Subsystem for Linux (WSL) 早已从最初的“玩具”蜕变为不可或缺的生产力工具。相信很多同学都知道WSL有两个版本，但多数同学并不清楚WSL1和WSL2的区别，咱们今天来介绍一下。
一、WSL到底做了什么？
很多人只在用 WSL，但并不清楚 WSL 真正的定位。WSL 的核心目标不是“模拟 Linux”，而是让你在 Windows 上以低成本获得一个可用的 Linux 用户态环境，并且让 Windows 和 Linux 双向打通、无缝协作。
为了直观看懂整体架构差异，先附上 WSL 整体运行全景图，清晰梳理用户层、WSL 运行时、两大版本底层内核、虚拟化底座的层级关系：
┌─────────────────────────────────────────────┐
│ Windows 应用 / 你（用户） │
│ Explorer · VSCode · Terminal · wsl.exe │
├─────────────────────────────────────────────┤
│ WSL 运行时 / 管理平面 │ ← 启动、挂载、网络、9P、WSLg
├─────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌════════════════════┐ │
│ │ WSL1 路径 │ 或 │ WSL2 轻量 VM │ │
│ │ syscall │ │ ┌──────────────┐ │ │
│ │ 翻译层 │ │ │ 真实 Linux │ │ │
│ │(无Linux │ │ │ kernel(MSoft) │ │ │
│ │ kernel) │ │ │ + distro rootfs│ │ │
│ └──────────┘ │ └──────────────┘ │ │
│ └════════════════════┘ │
│ Hyper-V 虚拟化底座 │
└─────────────────────────────────────────────┘
▲
│ 9P 协议 / virtio / AF_UNIX 管道
Windows 文件系统 ↔ Linux 文件系统互挂
注：WSL2 的“轻量 VM”并非传统 Hyper‑V 完整虚拟机，无 BIOS/GRUB，启动路径高度精简。
可见，WSL 所有能力都依托统一的运行时管理平面实现，核心差异集中在内核执行层，WSL1 与 WSL2 选择了两条完全不同的技术路线。
二、WSL1系统调用翻译 vs WSL2真实内核虚拟化
1. WSL1：无 Linux 内核，纯系统调用翻译的“模拟方案”
WSL1 的本质是运行在 Windows NT 内核之上的Linux 系统调用兼容层，全程没有任何真实 Linux 内核参与工作，所有 Linux 程序都靠“翻译适配”运行，具体工作逻辑如下：
程序加载：Linux 的 ELF 可执行文件，由 WSL 的 Pico provider 驱动在 NT 内核的 Pico 进程框架内完成加载与初始化，再由兼容层将 Linux 系统调用实时翻译为 NT 内核语义。
指令翻译：当 Linux 程序发起 open()、fork()、socket()、execve() 等系统调用时，WSL1 运行时会实时拦截，动态转换为等效的 Windows NT 内核操作指令。
用户态支撑：依托精简的自研 init 进程作为 PID 1，搭载从官方发行版提取的 rootfs 文件系统，完整保留 bash、apt、gcc 等 GNU 用户态工具，保证基础 Linux 命令可正常执行。
WSL1特点：
无任何 Linux 内核，全程复用 Windows NT 内核能力，“伪装”Linux 运行环境；
ELF 文件依靠 NT 驱动兼容运行，不依赖 KVM、虚拟机等虚拟化技术；
核心优势：访问 Windows NTFS 磁盘（/mnt/c）极致流畅，无跨系统开销，秒级启动、资源占用极低；
结构性硬伤：系统调用无法实现 100% 覆盖，ptrace、inotify、overlayfs、cgroup 等内核级特性天然缺失，进阶工具、容器、服务必然报错崩溃。
可见，WSL1用极致轻量化换兼容性，基础运维、简单脚本够用。但只要涉及内核级能力，就会陷入“系统调用猜谜”的结构性困境，上限极低。
2. WSL2：放弃翻译，原生运行真实定制 Linux 内核
微软彻底终结了 WSL1 的“翻译妥协方案”，WSL2 的核心逻辑：承认兼容层无法完美适配 Linux，直接通过高度优化的轻量虚拟机，运行官方维护的真实 Linux 内核，从根源解决兼容性问题。其核心工作机制分为六大模块：
（1）轻量专属 VM + 定制 Linux 内核
WSL2 搭载的并非传统笨重虚拟机，而是极简单用途 Hyper-V 轻量 VM，彻底摒弃了 BIOS、GRUB 等冗余启动流程，仅保留「Linux 内核 + 自研 init」核心组件，启动速度控制在 1-2 秒，兼顾虚拟化完整性与轻量化。内核由微软公开源码、独立维护，针对性适配 WSL 场景，内置 vmbus、virtio、内存气球动态调度、9P 协议优化等专属补丁，同时裁剪冗余模块，保证性能与兼容性平衡。
（2）内核与发行版 rootfs 完全剥离
WSL2 实现了内核与系统发行版的解耦：VM 仅负责运行统一的定制 Linux 内核，用户使用的 Ubuntu、Debian、Fedora 等发行版，本质只是独立的 ext4 格式 rootfs 镜像（VHDX 虚拟磁盘文件）。用户可随意切换、重装发行版，无需改动底层内核，灵活性极高。
（3）跨系统文件互通：核心依赖 9P 协议
9P（Plan 9）协议是 WSL2 实现 Windows 与 Linux 文件双向打通的核心胶水，彻底解决跨系统文件互访问题，也是其性能优缺点的根源：
Linux 访问 Windows 文件：WSL2 中，/mnt/c、/mnt/d并非直接访问 NTFS，而是通过9P协议 经 virtio 通道将 Windows 目录投射进 Linux；这一额外转发层正是跨系统文件访问存在延迟的根本原因。
Windows 访问 Linux 文件：Linux 专属 ext4 虚拟磁盘，通过 9P 反向暴露，Windows 可通过 \\wsl$\Distro\ 路径直接访问；
我们日常在 Linux 中执行code . 打开 Windows 目录项目、在资源管理器访问 WSL 本地文件，底层全部依赖 9P+virtio 通道+UID/GID 权限映射实现，这也是 WSL2 访问 /mnt 目录存在性能延迟的核心原因（跨协议转发存在开销）。
（4）网络机制：虚拟网卡 + 多模式网络适配
WSL2 拥有独立虚拟网卡（vNIC），依托 Hyper-V 虚拟交换机实现网络能力，完全区别于 WSL1 的网络共享模式：
默认 NAT 模式：Linux 独立私有 IP，可主动访问外网，外部无法直接主动访问 Linux 服务，安全性更高；默认通过 Hyper‑V 虚拟交换机（通常为 NAT 语义）实现网络隔离；Win11 及更新版本可在 .wslconfig中启用 mirrored模式，优化 IP 隔离问题，使 Linux 网络更贴近主机，适配更多调试场景。
自动端口转发：依托 localhostForwarding=true 机制，Linux 本地启动的服务（如 8000 端口），Windows 可直接通过 localhost 访问，无需手动配置映射，屏蔽了 NAT 隔离的使用门槛。
（5）进程与生命周期管理
WSL2 以自研 /init 作为 PID 1 核心进程，统一管控所有底层能力：负责全局挂载表管理、9P 文件系统挂载、binfmt 二进制兼容（支持 Linux 终端直接调用 Windows exe 程序），同时兼容转发系统初始化逻辑。Win11 新版本已原生支持 Systemd 模式，可无缝适配 Linux 自启服务、后台进程管理。而 wsl –shutdown、wsl -d 等命令，本质都是在管控轻量 VM 的生命周期与命名空间。
（6）WSLg 图形化与 GPU 加速
Win11 内置的 WSLg 技术，彻底补齐了 WSL 图形化短板：Linux 端的 X11/Wayland 图形程序，可通过 Weston/RDP 合成器，依托 AF_UNIX 管道与 virtio 通道，对接 Windows 远程桌面栈渲染窗口。最终实现 Linux GUI 应用原生窗口显示、剪贴板互通、音频回环，同时支持 GPU-PV 半虚拟化 CUDA 硬件加速，可流畅运行 AI 图形、算力任务。
三、优缺点对比
| 对比维度 | WSL1 | WSL2 |
|---|---|---|
| 底层架构 | 系统调用翻译层、Pico进程、无原生Linux内核 | 轻量化Hyper-V虚拟机、搭载微软定制Linux原生内核 |
| 系统调用兼容性 | 部分兼容，仅支持基础POSIX命令，内核级功能缺失 | 100%完全兼容，支持全部Linux内核特性与进阶服务 |
| Docker容器支持 | 缺失cgroups、namespace、overlayfs等内核机制，无法作为容器宿主机 | 原生完美支持，适配Docker、K8s完整容器生态 |
| 文件系统机制 | drvfs直接映射Windows NTFS目录，无虚拟化转发开销 | 独立ext4虚拟磁盘（vhdx），通过9P协议挂载Windows磁盘 |
| 跨文件性能 | 所有文件访问均需经过 syscall 翻译层，批量 I/O（git、npm、编译）性能明显弱于 WSL2 的 ext4 本地磁盘 | Linux本地ext4磁盘读写极速，跨系统/mnt文件读写延迟较高 |
| ELF二进制 | NT 加载器+兼容垫片模拟运行 | 内核原生执行，标准 Linux 运行机制 |
| 网络模式 | 共享Windows主机IP与网络栈，端口直通、零配置 | 独立虚拟网卡 + Hyper‑V 虚拟交换机（通常 NAT 语义），IP 动态变化；Win11 支持 mirrored 模式，端口自动映射。 |
| 高阶功能支持 | 不支持Systemd、IPv6、OverlayFS、cgroup v2 | 原生支持Systemd、IPv6、OverlayFS、cgroup v2 |
| GPU/GUI能力 | 无支持，完全受限 | 支持WSLg图形化、CUDA 硬件加速 |
| 硬件资源占用 | 极低，无虚拟化开销，完全依托Windows资源调度 | 动态分配资源，闲置自动释放内存/CPU，可控无冗余 |
| 启动速度 | 毫秒级瞬时启动，无任何延迟 | 秒级启动，略慢于WSL1，日常开发无感知 |
| 系统要求 | 最低要求为 Windows10 1709，但1809之后稳定性显著提升 | Windows10 1903+ / Win11全版本（推荐2004+） |
四、总结
WSL1是微软早期的轻量化过渡方案，依靠翻译层实现低开销运行，但内核兼容性存在天然缺陷，仅能满足极简运维、轻度命令使用场景。
WSL2是面向现代开发的生产级成熟方案，通过轻量化虚拟化技术补齐了所有内核短板，实现了100% Linux生态兼容，容器开发、算力调度、微服务调试、图形化应用等场景全面适配。唯一的跨系统文件读写短板，可通过规范项目存储路径完美规避。
两句话总结：
WSL1 是“能用 Linux 命令的 Windows 子系统”，WSL2 是“跑在 Windows 上的真实 Linux 运行环境”。
老旧设备、极度依赖 Windows ↔ Linux 高频互写、无需容器 → 可考虑WSL1；容器、编译、AI、微服务、生产级 Linux 行为 → 优先选择WSL2。
