WSL2真的在Windows内核旁边运行吗？只说对了一半 🧐

5 月 10, 2026

—

cslab

in IT Security

“WSL2与Windows内核并行运行”

— 这句话，一半正确，一半错误。

🎯 本文涵盖内容

WSL1和WSL2架构根本不同的原因
WSL2使用Hyper-V轻量级VM的结构及其意义
对“与Windows内核并行运行”这一说法的准确解读
WSL2 Linux内核的身份和管理主体
WSL1与WSL2的选择标准

📌 引入 / 背景

开发者在Windows上使用Linux的需求由来已久。以前，必须使用VirtualBox或VMware等传统虚拟机。它们笨重、缓慢，并且占用磁盘空间。

Microsoft于2016年推出的WSL1 (Windows Subsystem for Linux 1)是革命性的。它无需虚拟机即可运行bash shell。然而，其局限性也很明显。文件I/O速度慢，并且某些Linux系统调用不受支持，导致Docker等工具无法正常工作。

因此，在2019年，Microsoft发布了WSL2。从那时起，“WSL2与Windows内核并行运行”的说法开始流传。这种说法真的准确吗？

🔍 WSL1的结构 — 翻译器方式

要理解WSL2的变化，首先需要了解WSL1。

WSL1在没有Linux内核的情况下运行。它使用一个层，实时将Linux程序请求的系统调用(syscall)翻译成Windows NT内核API。

[Linux 바이너리 (bash, grep, vim...)]
          ↓ Linux syscall 발생
[WSL1 Translation Layer]  ← 번역기 역할
          ↓ 변환된 NT API 호출
[Windows NT Kernel]

这种结构的优点是轻量。由于没有VM，因此没有启动时间，内存开销也较小。

缺点是不完美。100%翻译Linux syscall几乎是不可能的。Docker守护进程所需的namespace、cgroup等内核功能未能得到良好支持。

🔍 WSL2的结构 — 轻量级VM方式

WSL2彻底改变了其方法。它运行一个真正的Linux内核。

核心是Hyper-V轻量级虚拟机(Lightweight Utility VM)。在Windows内置的Hyper-V管理程序之上启动一个非常小的VM，并在其中运行由Microsoft直接管理的自定义Linux内核。

┌─────────────────────────────────────────────┐
│            Hyper-V Hypervisor               │
├──────────────────┬──────────────────────────┤
│  Windows 파티션  │    WSL2 VM 파티션         │
│  Windows NT      │    Linux Kernel           │
│  Kernel          │    (Microsoft 커스텀)     │
│                  │    + Linux 사용자 공간    │
└──────────────────┴──────────────────────────┘

这种结构有两个重要点。

🔑 要点1 — Hyper-V居中

WSL2并非直接与Windows内核并行运行。相反，Windows和Linux作为独立的分区运行在名为Hyper-V的管理程序之上。

“并行运行”的说法并非完全错误。两个内核同时加载到内存中并独立运行，因此从广义上讲可以认为是并行的。但更准确地说，它是“管理程序上的两个分区”。

🔑 要点2 — Linux内核的身份

WSL2中使用的Linux内核是由Microsoft直接维护的开源自定义内核。

其地址是github.com/microsoft/WSL2-Linux-Kernel，它基于标准Linux内核并针对WSL2环境进行了优化。

运行wsl --update命令会更新此内核。它不会更新Ubuntu或Debian的内核。

🔍 “并行”一词从何而来

即使是Microsoft的官方文档在描述WSL2时也使用了这种表达：

WSL 2 uses virtualization technology to run a Linux kernel inside of a lightweight utility virtual machine (VM).

一些演示文稿或YouTube视频也使用“Windows内核和Linux内核并行运行”的可视化。这旨在从用户的角度轻松传达两个操作系统同时运行的概念。

然而，对于熟悉管理程序架构的人来说，这种描述可能会引起一些误解。更准确的说法是：

“Windows分区和Linux VM分区在Hyper-V管理程序之上共同运行。”

💻 实践 — 直接验证WSL2结构

您可以直接验证WSL2的VM结构。

检查WSL2内核版本

# 在WSL2 shell中运行
uname -r
# 输出示例: 5.15.167.4-microsoft-standard-WSL2

附带了microsoft-standard-WSL2后缀。这是Microsoft自定义内核的证据。

在Windows中检查Hyper-V VM

# 在PowerShell (管理员)中运行
hcsdiag list

WSL2实例会作为Hyper-V容器VM显示在列表中。

检查内存使用结构

# 使用CLI而非任务管理器查看
Get-Process -Name "Vmmem" | Select-Object Name, WorkingSet

可以看到Vmmem进程。这是WSL2 VM使用的内存。这是真实VM正在运行的证据。

使用.wslconfig限制内存/CPU

由于WSL2是VM，因此可以限制资源。在%USERPROFILE%.wslconfig文件中进行设置。

# C:Users<用户名>.wslconfig
[wsl2]
memory=4GB       # 分配给VM的最大内存
processors=2     # 分配给VM的CPU核心数
swap=2GB         # 交换文件大小

🆚 WSL1 vs WSL2 — 如何选择


项目	WSL1	WSL2
架构	系统调用翻译	Hyper-V 轻量级VM
Linux 内核	无 (翻译器)	真实内核
文件I/O (Linux 文件系统)	慢	快
文件I/O (Windows 文件系统)	快	慢 (9P 协议)
Docker 支持	有限	完全支持
系统调用兼容性	部分	几乎完美
启动时间	即时	数秒 (首次运行)
需要 Hyper-V	不需要	需要

在一般的开发环境中，WSL2具有压倒性优势。Docker Desktop也推荐WSL2后端。

在需要大量读写Windows文件系统(/mnt/c/…)的特殊情况下，WSL1可能更快。但这种情况很少见。

⚠️ 注意事项 / 常见错误

🚨 文件应放在Linux文件系统内

在WSL2中处理/mnt/c/（Windows文件系统）中的文件时，由于数据必须通过9P协议跨越VM边界，I/O会变慢。建议将项目文件夹放在~/（Linux主目录）内。

🚨 Hyper-V与其他虚拟化软件冲突

旧版VirtualBox或VMware可能与Hyper-V冲突。激活WSL2会开启Hyper-V，这可能导致VirtualBox 6.0及以下版本出现问题。VirtualBox 6.1及以上版本或VMware 15.5.5及以上版本可以与Hyper-V共存。

🚨 wsl --shutdown会关闭VM

在使用WSL2时，如果运行wsl --shutdown，它不仅会终止Linux进程，还会关闭VM本身。下次运行wsl命令时，VM将重新启动（需要几秒钟）。

✅ 总结 / 结尾

WSL2的核心要点总结如下：

WSL1是无需Linux内核，通过翻译系统调用的方式。
WSL2是在Hyper-V上的轻量级VM中运行真实的Linux内核。
“与Windows内核并行运行”严格来说是不准确的说法 — 更准确地说，是管理程序上的两个分区。
WSL2 Linux内核是Microsoft直接维护的开源自定义内核。
Vmmem进程证明了VM的存在。

WSL2是一个折衷方案，它提供了“既不像虚拟机那样笨重，又是真正的Linux”。了解其结构将使性能调优和故障排除变得更加容易。

下一步可以探讨WSL2 + Docker Desktop架构、WSLg（GUI应用支持）以及Windows 11中WSL2的改进等。