WSL 容器 GA 拆解：微软的 2 倍性能是真的，但先别急着卸 Docker
本文完全由 WorkBuddy 独立收集资料、调试代码并完成文章写作。
我是 Alex Xiang，前百度/微博工程师，现在专注于 AI 工程与工具产品。更多文章欢迎关注微信公众号「字与码」。
9 月 29 日，微软把 WSL 容器（WSL Containers，社区简称 WSLC）从公开预览转成了正式可用，随 WSL 3.0.1 发布，升级方式就是一句 wsl —update。核心是一条新命令 wslc.exe，另有一个别名 container.exe，命令语法基本照着 Docker 抄。微软给它的说法很直白：不用再装 Docker Desktop，Windows 自带就能跑 Linux 容器。
同一批还交付了三件事：文件系统换成 virtiofs，官方口径是访问 Windows 文件快约 2 倍；网络换成一个叫 Consommé 的新模型；以及面向企业的 Intune 策略和 Defender for Endpoint 覆盖。
这篇文章想说清四件事：这 2 倍到底是谁的 2 倍；wslc 与 Docker 的真实差距落在哪些地方；微软为什么这次把管理能力跟运行时一起首发；以及今天该不该在你的开发机上把它打开。
先给结论。如果你只是要起个数据库、跑一两个单容器、或者长期被 Windows 与容器之间的文件读写折磨，现在就可以装。如果你的日常是一份 compose.yaml 拉起五六个服务，现在的答案是「等」，不是「换」。而全文最要紧的一句是——那 2 倍是文件系统的功劳，不是运行时的功劳。把这句话想清楚，你会省下很多无谓的迁移。
顺带先清一个谣：WSL 3.0.1 不等于「WSL 3」。微软已经明确否认存在这个新大版本，3.0.1 只是版本号，架构上它还是 WSL 2 那一套轻量虚拟机。很多自媒体把版本号读成了代际升级，这不是事实。
十年才补上的一块拼图
把时间线摆出来，这件事的位置就清楚了。
| 时间 | 事件 | 意味着什么 |
|---|---|---|
| 2016 | WSL 1 发布 | 用翻译层让 Linux 二进制跑在 Windows 内核上，兼容性有限 |
| 2019 | WSL 2 发布 | 换成真正的轻量虚拟机 + 完整 Linux 内核，架构定型至今 |
| 2025 年末 | WSL 2 开源 | 底层进入 microsoft/WSL 仓库公开开发 |
| 2026 年 6 月 | Build 2026 宣布 WSL 容器 | 承诺「不用第三方工具也能跑容器」 |
| 2026 年 6 月 29 日 | 首个公开预览（WSL 2.9.3） | 需要 wsl —update —pre-release 才能拿到 |
| 2026 年 9 月 29 日 | 正式可用（WSL 3.0.1） | wsl —update 即可；补齐重启、文件拷贝、健康检查、事件流等 |
| 2026 年 10 月起 | Intune 仪表盘支持铺开 | 从「能装」走到「IT 能管」 |
注意一个细节：微软在正式版里补的东西，几乎全是为「日常开发和自动化」准备的——容器重启与可配置的停止超时、wslc container cp（按 tar 归档方式拷进拷出）、健康检查、wslc events 实时事件流、网络连接与断开、—mount 挂载支持、可配置的存储路径、wslc system info。这些都不是玩具功能，是有团队真拿它当工作流之后才被要出来的东西。这说明预览期的真实用户不少，而且用得挺深。
它到底是什么：两条腿，不是一条
大部分人只注意到 CLI，其实 WSL 容器由两个组件构成，第二条腿可能比第一条更有长期价值。
第一条腿是 wslc.exe，随 WSL 内置，不需要额外装引擎。它说的是 Docker 方言，run、build、exec、logs、-d、-p、—rm 这些肌肉记忆可以直接搬过来：
wslc run --rm -it ubuntu:latest bash -c "echo Hello from WSL container"
wslc run -d --rm -p 8080:80 --name web nginx
wslc image list
wslc container list --all
wslc stats镜像是标准 OCI 镜像，Docker Hub 的、ghcr.io 的都能拉。官方文档没有把「OCI 兼容」写成正式承诺，但实际可以跑。也就是说，你现有的镜像清单不需要重建。
第二条腿是 WSL 容器 API，走 NuGet 包 Microsoft.WSL.Containers，提供 C、C# 和 C++/WinRT 三种投影，能和 MSBuild、CMake 集成。API 围绕四个对象组织：WslcService（检查依赖、查版本）、Session（管镜像、建容器）、Container（启停、查状态、在里面跑进程）、Process（读写 stdin/stdout/stderr、发信号、拿退出码）。
第二条腿为什么重要？因为它意味着一个 Windows 应用可以把 Linux 容器当成自己的一个内部组件——用它跑 ffmpeg、跑推理服务、跑一段只有 Linux 才有的数据处理管线，而不需要用户先去装一个容器平台。Docker 从来没有提供对等的路径：它绕不开那个常驻守护进程，你没法把一个 daemon 优雅地塞进别人的桌面应用里。Build 2026 的演示里就有把一个 Linux 渲染器打包成 Windows 可执行文件、把容器化的 Linux 桌面流进 WinUI 3 应用、以及从 Windows 前端调用带 GPU 的 PyTorch 这些场景。
顺带说清一个容易被自媒体带偏的点:每个容器不是各自一个虚拟机。具体看下一节。
架构：三处真正的重新设计
第一处，会话与权限模型。 普通 WSL 里，应用跟一个有特权的 Windows 服务 wslservice.exe 打交道，由它创建和管理虚拟机，虚拟机一直归这个服务所有。WSL 容器不一样：wslservice.exe 会创建一个子进程 wslcsession.exe，以调用者的用户权限运行，由它去建容器、挂载目录、绑定端口。每个会话一个虚拟机、一个虚拟硬盘（默认落在 %AppData%\Local\wslc\sessions）。
这个设计有两个直接后果，一好一坑。
好的一面是隔离与权限收敛：会话操作跑在比 wslservice.exe 更低的权限上，多用户开发机和 CI runner 上的共享守护进程问题被绕开了。
坑的一面是——会话是按「用户身份 + 是否提权」切分的。在普通控制台和提权控制台里跑 wslc，会得到两个不同的会话（例如 wslc-cli-<用户名> 和 wslc-cli-admin-<用户名>），各自的虚拟机、各自的硬盘，镜像、容器、卷互不可见。如果哪天发现容器「不见了」，第一件事是确认你现在这个控制台和当初创建它的是不是同一种。最省事的做法是：定一种，一直用它。日常开发用普通控制台就够了。
第二处，文件共享从 Plan 9 换成 virtiofs。 这是全文最值得细看的一处，下一节专门拆。
第三处，网络模型 Consommé。 这个名字来自微软开源虚拟机监控器 OpenVMM，前身叫 VirtioProxy。做法是：Linux 虚拟机里的流量以太网帧的形式进入 virtio 队列，再由一个以用户身份运行的 Windows 进程来处理 DNS 查询、转发 TCP/UDP、做端口映射。
为什么这件事重要？因为容器工具在 Windows 上的老毛病之一是网络——公司 VPN 一开，容器就断网；企业代理和防火墙策略在 Linux 虚拟机里看不见，得逐个配。Consommé 的思路是让容器流量走使用者本人的 Windows 网络栈，于是它天然继承 VPN、代理、防火墙策略。这大概是整个 GA 里最实用、也最被低估的一项。但要说清：微软自己仍然把它标为实验性网络模式，不同 VPN、代理、特殊网络环境需要逐个验证，不能假定一次就通。
还有一项没被重点宣传但同样实在的改进：内存回收。Linux 虚拟机里闲置的内存会被更平缓、更持续地还给 Windows 宿主。
最后是一个关键的时间差：这三项（virtiofs、Consommé、内存回收）动的都是文件系统和网络这类关键路径，所以微软先在 WSL 容器里默认开启，WSL 发行版本体暂时还是可选，目标才是将来在 WSL 里默认打开。
「2 倍」到底是谁的 2 倍
这是全文最需要较真的一节。微软的官方措辞是「Linux 环境访问 Windows 文件最高快 2 倍」，但对照基准是 Plan 9，不是 Docker。 ComputingForGeeks 做过一组可复现的实测（三次运行取中位数，单位毫秒），结果如下：
| 存储路径 | 建 2000 个文件 | stat | 读 | 删 | 写 256MB | 读 256MB |
|---|---|---|---|---|---|---|
| wslc 绑定 C:\（virtiofs） | 21,712 | 9,025 | 26,397 | 10,771 | 7,902 | 1,784 |
| WSL 发行版 /mnt/c（9P） | 51,850 | 25,550 | 75,655 | 15,365 | 22,323 | 15,110 |
| WSL 里的 Docker，/mnt/c 绑定（9P） | 51,946 | 25,663 | 76,795 | 16,775 | 24,745 | 14,632 |
| wslc 容器文件系统 | 297 | 48 | 142 | 75 | 2,316 | 57 |
| wslc VHD 卷（ext4） | 180 | 50 | 94 | 52 | 2,559 | 61 |
| WSL 发行版 ext4 磁盘 | 209 | 69 | 108 | 59 | 2,579 | 68 |
| WSL 里的 Docker，overlay 文件系统 | 267 | 55 | 119 | 60 | 2,264 | 66 |
从这张表能读出四个结论，每一个都比「快 2 倍」这句宣传语更有用。
第一，2 倍是 virtiofs 相对 9P 的 2 倍，不是 wslc 相对 Docker 的 2 倍。 逐项算：建文件快 2.4 倍、stat 快 2.9 倍、读快 2.9 倍、顺序写快 2.8 倍、顺序读快 8.5 倍（143 MB/s 对 17 MB/s）。微软的「最高 2 倍」是个保守表述，顺序读上实际差距大得多。
第二，注意表里 Docker 那一行。 WSL 里的 Docker 走 /mnt/c 绑定时，每一项都落在裸 WSL 发行版 /mnt/c 的 10% 以内。这条数据把网上很多说法证伪了——瓶颈是 9P 本身，不是容器运行时。换运行时不会让你快 2 倍，换文件系统才会。而 wslc 只是「默认帮你把这个开关打开了」。
第三，真正的数量级差距在「数据放哪」，不在「用哪个运行时」。 同样建 2000 个文件：virtiofs 挂载要 21.7 秒，wslc 的 VHD 卷只要 0.18 秒，差约 120 倍；读回来差约 280 倍。而在虚拟机内部的存储上，wslc 和 Docker 基本打平（VHD 卷 180ms / 容器文件系统 297ms，Docker overlay 267ms）。
第四，由此得到一条比「换不换工具」重要得多的操作建议。 源码目录放 Windows 绑定挂载没问题，但把依赖树和构建缓存挪到虚拟机内部的卷上——node_modules、.venv、target/ 这类小文件海量、反复读写的目录，用命名卷或 VHD 卷接进去。这一个目录布局决定的收益是两个数量级，远超选 wslc 还是选 Docker 的差别。 很多人抱怨「Windows 上跑容器慢」，其实抱怨错对象了。
必须说明这组数字的可信度边界。测试机本身是 Proxmox 上的一台虚拟机，容器虚拟机跑在嵌套虚拟化里，每一次跨越 Windows 边界的文件操作都要多付一层虚拟机退出的代价——裸机上绝对耗时会更低，但比例关系大致成立。其次，256MB 的顺序读打到了页缓存，应视为上限而非磁盘速度。还有一条很关键的坑：全新会话的第一次 virtiofs 运行，建文件花了 471 秒，之后两次才稳定到 21 秒上下。所以任何自己做的对比测试，先热身再测，否则你会得出完全错误的结论。
最后，virtiofs 在 WSL 发行版本体上目前还是 opt-in，需要自己在 %USERPROFILE%.wslconfig 里加：
[wsl2]
virtiofs=true然后 wsl —shutdown 重启。进去用 findmnt -T /mnt/c -o TARGET,SOURCE,FSTYPE,OPTIONS 验证，FSTYPE 应该显示 virtiofs 而不是 9p。三个注意事项：这个键还没进官方 .wslconfig 文档，当成实验特性用；virtiofs 的性能补丁需要内核 6.18.26.3-1 或更新，否则 WSL 会打警告并退回慢路径；2.7.7 与 2.7.8 上有真 bug——某个固定盘共享失败会静默跳过所有盘的自动挂载，/mnt/c、/mnt/d 直接不存在，dmesg 里什么都没有。所以这条开关不适合在有硬期限的项目上贸然打开。
与 Docker 的正面对比
一句话概括两者定位：Docker Desktop 是一个平台，wslc 是一个运行时。把它当产品比，wslc 在功能上输、在重量和授权上赢；把它当运行时比，它在文件 I/O 上赢、在密度上不一定。
| 维度 | WSL 容器（wslc） | Docker Desktop |
|---|---|---|
| 出品方 | 微软 | Docker, Inc. |
| 授权 | 开源（microsoft/WSL 仓库），随 Windows 免费 | 专有；企业规模需订阅 |
| 安装 | 内置，wsl —update | 需单独安装软件 |
| 后台守护进程 | 无（按需启动虚拟机） | dockerd 常驻 |
| 空闲内存 | 空闲时接近 0 | 典型 1–2 GB |
| 宿主文件共享 | virtiofs，官方称最高快 2 倍 | 9p / gRPC-FUSE |
| 网络 | 走 Windows 用户态进程，继承 VPN/代理/防火墙策略 | NAT + 端口代理，VPN 需额外配置 |
| GPU 直通 | 支持，—gpus | 支持，—gpus |
通用设备直通（—device） | 无 | 有 |
—network host | 无（明确不支持） | 有 |
| 健康检查 | 有（—health-*） | 有 |
| 容器重启 | 有（GA 新增） | 有 |
pause / top / commit | 无 | 有 |
system prune / system df | 无（只能按对象逐个 prune） | 有 |
| 重启策略（restart policy） | 无 | 有 |
| Docker Compose | 无（开发中，官方列为最高优先级需求） | 内置 |
| Kubernetes | 无 | 内置 |
| Swarm | 无 | 有 |
| buildx 多平台构建 | 无 | 有 |
| 图形界面 | 无官方界面；社区有 WSL Container Desktop（较基础） | 完整 GUI + 扩展生态 |
| Windows 容器 | 不支持（仅 Linux） | 支持 |
| 面向 Windows 应用的编程 API | NuGet 包，原生支持 | 无对等能力 |
GPU 那一行需要打个折扣：正式版确认 —gpus 可用，官方也把「本地 AI 负载」列为目标场景，但关于容器内 GPU 直通的成熟度，发布材料着墨很少。如果你要靠它跑本地推理，得自己先验。
九个你会真撞上的缺口
Compose 是明面上的第一缺口，但只盯它一个会误判。把社区在预览期到正式版之后反复提到的问题合起来数，实际有九个。
一、没有 Compose。 微软把 wslc compose 列为「最高优先级功能需求」，目标是让现有的 compose.yaml 不改一个字就能跑，但没有给出日期。你的本地环境如果是一个数据库、一个缓存、三个服务通过一份 YAML 串起来的，wslc 现在不足以接替。
二、WSL 发行版文件系统里的仓库没法绑定挂载进容器。 这条比 Compose 更隐蔽，也更致命。你可以在 Windows 目录和虚拟机内部卷之间挂载，但「在 Ubuntu 的 ~ 里 clone 一个仓库，然后拿它跑容器」这个主流工作流，官方在 issue 里的答复是暂不支持。有独立测试把它称为「最大的单一阻塞项」。如果你的习惯是先 clone 到 WSL 里再动手，wslc 今天就不适合你。
三、没有 —privileged 和 —device。 直接后果是容器里跑不了 Docker（Docker-in-Docker），USB 设备直通也没有。
四、build 没有 —platform 参数。 devcontainers CLI 会因此出问题。
五、没有重启策略。 容器崩了不会自动回来，得自己加一层外部守护或健康检查逻辑。
六、没有 —network host，官方明确拒绝。 需要宿主网络栈的场景要改架构。
七、没有 system prune / system df。 只能按对象类型逐个清理，长期使用会积累出「磁盘去哪了」的困惑。
八、硬编码 Docker 的工具链不认识它。 .NET Aspire、az acr login 这类默认假设 docker 存在。Aspire 后来加上了把 WSL 容器当运行时用，但这类适配是逐个补的，不是系统性的。VS Code 侧的情况好一些：Dev Containers 扩展从 0.462.0 预览版起支持，做法是把设置里的 Docker Path 改成 wslc，和当年把 Podman 接进去的做法一样。VS Code Containers 扩展、Dev Containers CLI 也陆续支持了。
九、没有 Kubernetes、没有 Swarm、没有 buildx 多平台。 需要这三样中任何一样的团队，迁移论题不成立。
把这九条摆在一起，结论就清楚了：缺 Compose 只是冰山一角，真正的问题是没有 —privileged/—device、没有 host 网络、没有多平台构建、没有发行版文件系统的绑定挂载。 这四样合起来，决定了它当前是一个「跑单个容器很好用」的运行时，而不是一个「能覆盖完整本地开发栈」的平台。
企业那一刀，才是微软真正的目标
如果只看技术，WSLC 是个不错的补全；但把企业管控的部分和 Docker 的授权条款放在一起看，意图就非常明确了。
Docker Desktop 的免费范围是：个人、教育、非商业开源，以及同时满足「员工少于 250 人」且「年营收低于 1,000 万美元」的公司。跨过任一条，商业使用就需要付费：Pro 每用户每月 9 美元（年付）、Team 15 美元（上限 100 席）、Business 24 美元（无年付折扣，即每年 288 美元）。
换算成团队规模就很直观：
| 使用人数 | Team（年） | Business（年） |
|---|---|---|
| 10 人 | $1,800 | $2,880 |
| 30 人 | $5,400 | $8,640 |
| 100 人 | $18,000 | $28,800 |
| 200 人 | 超席位上限 | $57,600 |
| 500 人 | 超席位上限 | $144,000 |
也就是说，一家刚跨过 250 人门槛、有 30 名开发者日常在用 Docker Desktop 的公司，一夜之间多出每年 5,400 到 8,640 美元的账单，而且这张账单不随使用频率变化——一个月开一次容器的人和一个一天开五十次的人，价格一样。
对照之下，WSLC 随 Windows 内置，没有额外授权费，而且企业管控能力是跟运行时一起首发的，不是事后补的：
- 组策略 / Intune：ADMX 策略可以分别控制「能不能用 WSL 发行版」和「能不能用 WSL 容器」，还能设置镜像仓库白名单（Intune 里的两个设置项叫 Allow WSL containers access 和 WSL containers registry allow list）。正式发布时 GPO 已可用，Intune 仪表盘的官方支持在随后几周铺开。
- Microsoft Defender for Endpoint：原有的 WSL 插件扩展为能感知 Linux 容器事件，提供进程、文件、网络活动的可见性，并能把容器活动关联回 Windows 宿主。用发行版还是用容器，覆盖面一致。
微软自己把这个动机说得挺直白：「如何控制组织内允许使用哪些发行版和 Linux 镜像」，是客户排名很靠前的诉求，而容器加仓库白名单让这件事变得容易。换句话说，IT 部门最头疼的「开发机上跑着一堆来路不明的 Linux 镜像」，被做成了一个可策略化的开关。
不过要配一条提醒。微软自己的企业 WSL 指南里写得很清楚：Windows 的管理工具覆盖不到 Linux 环境的所有部分，用 Windows 工具去更新和打补丁 Linux 发行版与软件包仍然不受支持，官方建议用 Linux 侧的配置管理工具来管用户空间。所以 MDE 能「看见」不等于合规闭环已经建好。「可见性」和「可控性」之间还差一层。
该不该采用
我不打算给一个笼统的「值得」或「不值得」，那没有信息量。按工作流分三层说。
现在就装，值得一试的：
- 只需要单容器或个位数容器——本地起 postgres、redis、nginx、一个消息队列。这类场景 wslc 的体验已经很顺，命令熟、启动快、空闲不占内存。
- 长期受困于 Windows 与容器之间的文件 I/O——前端热重载、跨边界编译。virtiofs 是这轮里最实在的收益。
- 要开发 Windows 应用但需要内嵌 Linux 能力——利用 NuGet API，让 Windows 应用把 Linux 容器当内部组件调，这是 Docker 没有对等能力的路径，也是微软真正的战略落点。
- 受 Docker 授权费困扰，但团队工作流对 Compose 依赖很轻——20 到 30 人规模每年省下的 5,400 到 8,640 美元是实钱，而迁移成本按标准工作流算只有每人大约 1 到 2 小时。
观望，现在换不划算的：
- Compose 重度依赖的团队——这是硬阻塞。复杂 Compose（构建密钥、自定义网络、
depends_on的健康条件、host 网络）的迁移成本要按每人 4 到 8 小时估，这个成本可能超过一整年的授权费，而且换过去功能还是缺的。 - 用 Testcontainers 做测试的团队——生态还没跟上。
- 需要 K8s、Swarm、buildx 多平台的团队——能力缺失，迁移论题不成立。
- 脚本里直连 Docker socket 或硬编码 docker 命令的——迁移前必须先把这类地方清出来测。
- 需要 Docker-in-Docker 或 USB 直通——没有
—privileged/—device，直接否掉。
不建议动的：
- 已经在 WSL 发行版里自己跑 Docker Engine 或 Podman 的人——你们的瓶颈同样不在运行时；virtiofs 下沉到发行版才是你要的，而不是换工具。
- 混合 Mac / Windows / Linux 的团队——工具链统一的价值大于单机收益。
如果你想试，我的建议是这条路径：先在一两个非关键项目上验证，把文件布局（依赖树放虚拟机内卷）先调对，等两件事落地再评估全面迁移——Compose 上线，以及 virtiofs 和 Consommé 下沉到 WSL 发行版本体。 到那时候，你很可能发现真正的收益早就拿到了，因为这两件事对所有人都生效，跟用不用 wslc 没关系。
我的五个判断
一，微软的目标其实不是 Docker Desktop，是让 Windows 应用能内嵌 Linux 运行时。 CLI 兼容只是拉新的钩子，NuGet API 才是长期资产。前者争夺的是「我该装哪个工具」，后者解决的是「我这个 Windows 程序需要一个 Linux 组件」。后者是 Docker 结构上无法提供的。
二，「2 倍」该读成文件系统的升级公告，不是运行时的胜利宣言。 既然 Docker 在 9P 路径上的表现与裸发行版只差 10% 以内，那 virtiofs 一旦在 WSL 里默认打开，Docker Desktop、Podman Desktop、Rancher Desktop 全都会一起受益——微软自己在博客里也是这么说的。所以真正的赢家可能是那些不用换运行时就能吃到红利的工具。
三，Compose 一天不落地，wslc 就只能吃掉 Docker 的长尾。 而按付费门槛算，这条长尾恰好很值钱——个人开发者、小团队本来就是免费的，真正在付费的是中大型企业，而他们恰恰是 Compose 和 K8s 用得最重的那批人。微软现在能拿下的，是「起个数据库」这类需求；拿不下的是「一份 YAML 拉起整个栈」这类需求。这个错位在 Compose 发布之前不会改变。
四，免费加可管控的组合，会先在采购环节赢，在工程环节后赢。 想想决策链：法务和采购看到的是「零授权费 + 原生 GPO/Intune 策略」，工程师看到的是「没有 Compose」。在企业里，这两个声音不是同等权重的。所以真实路径会是：采购先松口，工具装到机器上，工程师先在单容器场景用起来，然后单容器场景一点点长大——直到 Compose 落地那天完成交接。
五，Consommé 的价值被明显低估了。 容器网络在 Windows 上跟企业 VPN、代理、防火墙打架，是很多人真实的日常痛点，这几年一直靠打补丁绕。如果 Consommé 真的稳，受益面远超 wslc 本身。但要按实验特性对待，逐环境验证，别在关键路径上赌它。
最后一条观察，关于分寸。这轮发布里最容易被忽略的话，恰恰是最该记住的：微软自己把 Consommé 标为实验性，把 C++/WinRT 投影标为预览（可能发生破坏性变更），把 Compose 标为「开发中、无日期」，并承认 Windows 管理工具覆盖不到 Linux 用户空间。一个厂商愿意在正式版发布时说清自己缺什么，通常比它说清自己有什么更值得信任。 接下来几个 WSL 版本值得盯，尤其是 Compose 和 virtiofs 下沉这两件。
参考资料
- WSL container（官方概览） — 一手来源。wslc.exe 与 WSL 容器 API 的官方定义、版本要求（WSL 2.9.3+）、CLI 示例命令、NuGet 包与 C#/C++ 代码样例。
- Get started with containers on WSL（官方教程） — 官方上手教程，含安装验证、镜像拉取、后台运行与端口发布、构建自定义镜像的完整步骤。
- WSL container is now available for public preview（微软命令行博客） — 公开预览公告原文，virtiofs「快 2 倍」、Consommé 网络、内存回收、Intune/GPO 管控、MDE 容器事件、VS Code Dev Containers 0.462.0 支持 wslc 的第一手说明。
- WSL 容器架构深度解析（Pierre Boulay，微软高级软件工程师，9 月 29 日） — wslcsession.exe 降权会话模型、每会话独立 VHD、virtiofs 相对 plan9 的性能说法、Consommé 的流量路径，全部出自这篇。
- WSL Containers Go GA, Giving Windows a Built-In Linux Container Runtime With Its Own CLI（Hardware Busters） — 正式版功能清单、架构深潜要点、Compose 缺失与 GPU 着墨少的独立评述。
- WSL Containers (wslc) Tested: Benchmarks vs Docker（ComputingForGeeks） — 本文实测数据表的唯一来源，含完整测试脚本、三次取中位数的口径，以及嵌套虚拟化、页缓存、首次运行 471 秒这三条可信度边界。
- WSL Containers vs Docker Desktop: Honest Comparison（WSL Containers 指南） — 功能矩阵与「daemon vs 无 daemon」架构对比的交叉核对来源，明确列出九类能力缺失。
- How to Get Started with WSL Containers and wslc on Windows（IT-Connect） — wslc 与 Docker Desktop 的逐项对照表、「普通控制台 vs 提权控制台产生两个会话」这个实践坑，以及 Consommé 前身为 VirtioProxy、来自 OpenVMM 的出处。
- Microsoft Makes WSL Containers Generally Available, Adds Enterprise Controls（ADTmag） — 企业管控角度最完整的一篇，含「Windows 管理不能覆盖 Linux 用户空间补丁」这条官方提醒。
- WSL containers GA: wslc.exe, Intune controls, no Compose（The Terminal） — 两个 Intune 设置项的确切名称、会话磁盘路径
%AppData%\Local\wslc\sessions、virtiofs 与 VHD 卷两种存储形态。 - WSL Containers, virtiofs and a 6.18 Kernel: What’s Coming in WSL（WSL UI） — virtiofs 在发行版上 opt-in 的 .wslconfig 写法、验证命令、内核 6.18.26.3-1 要求，以及 2.7.7/2.7.8 三个已知 bug 的 issue 编号。
- Docker Desktop licensing cost: the 2026 price tiers（DevToolHub） — 250 人 / 1,000 万美元双门槛的条款原文引用、各档价格与不同团队规模的年度成本表、迁移工时的估算区间。
- Microsoft Makes WSL Containers Generally Available, Shipping the wslc.exe CLI and a Windows API in WSL 3.0.1（The Machine Herald） — GA 新增命令清单、社区工具（Lazywslc、WSL Container Desktop）与「Compose 无时间表」的交叉核对。
- 实用命令速查（本文用到的） —
wslc version、wslc run —rm hello-world、wslc image list、wslc container list —all、wslc stats、wslc system info、wslc events、wslc container cp。
微信公众号
欢迎关注「字与码」
如果这篇文章对你有用，也欢迎在微信里继续关注后续更新。
X / Twitter
关注 @ax2_zicode
更即时的技术观察、新文章提醒和一些短想法会发在 X 上。