📋 摘要：微软把 Linux 容器能力直接内建进了 WSL——一个 Docker 风格的 wslc 命令行、一套给 Windows 应用的容器 API、还有提速 2 倍的文件系统。它和 Docker 什么关系、现在能不能替代、怎么尝鲜，一篇讲透。

⏱ 阅读时长：约 7 分钟 ｜ 👥 适合：WSL 用户、开发者、在 Windows 上装过 Docker Desktop 的所有人

一、先澄清：这不是 WSL 3

这两天国内科技媒体集中报道了一件事——Windows 终于原生支持跑 Linux 容器了，不用装 Docker。不少读者在后台问我们怎么看，今天统一聊透。

这个功能叫 WSL Containers，微软在 Build 2026 开发者大会上首次公布，6 月底开放公开预览，最近随着国内媒体的报道，热度起来了。

先把一个误传纠正掉。部分媒体把它称为「WSL 3」，微软负责 WSL 的产品经理 Craig Loewen 专门澄清过——不存在 WSL 3。WSL Containers 不是 WSL 2 的版本继任者，而是基于现有 WSL 基础设施构建的新功能层。

这个定位很重要。它不是推倒重来，而是在你已经装好的 WSL 上，直接加了一层容器能力。你的发行版、你的配置、你的数据，都不动。

一句话概括它干了什么——以前你在 Windows 上跑 Linux 容器，要装 Docker Desktop 或者 Podman；现在 WSL 自己长出了 build、run、调试容器的能力。

二、wslc.exe：Docker 用户的肌肉记忆，直接复用

WSL 更新到预发布版后，你的 PATH 里会多出一个 wslc.exe。微软还附赠了一个 container.exe 别名，叫 wslc 还是叫 container，随你习惯。

最舒服的一点是命令格式和 Docker 高度相似，官方的说法是「保留你现有的肌肉记忆」。

看官方博客给的例子，直接在 Windows 上跑一个完整的 Linux 桌面环境：

wslc run -d --name=webtop -e PUID=1000 -e TZ=Etc/UTC -p 3000:3000 lscr.io/linuxserver/webtop:ubuntu-kde

这些参数你闭着眼都认识——-d 后台运行、-e 注入环境变量、-p 端口映射。镜像直接从公开仓库拉，跟 docker run 一个写法。

跑 AI 的同学更熟悉这个：

wslc run --rm --gpus all pytorch/pytorch:2.5.1-cuda12.4-cudnn9-runtime python -c "import torch; print(torch.cuda.is_available())"

--gpus all 直接透传 NVIDIA 显卡，在容器里一行 Python 验证 CUDA 可用性。对在 Windows 上搞深度学习的开发者来说，这一行就是刚需。

一个来自官方评论区的小坑值得提前说。有用户跑 wslc start hello-world 报「Catastrophic failure」，其实应该用 wslc run——start 是启动「已经停止的容器」，run 才是「没有镜像就拉、没有容器就建」。这个语义区分和 Docker 一致，但报错信息还比较生硬，预览阶段多包涵。

三、另一半拼图：给 Windows 应用的容器 API

wslc 是给人在终端里用的。但微软这次真正的野心，是另一半——让原生 Windows 应用把 Linux 容器当积木一样，直接编进自己的程序逻辑里。

WSL 发布了一个 NuGet 包，支持 C、C++、C# 三种语言。你的 Windows 程序可以直接通过 API 创建、运行、管理 Linux 容器，典型场景有三个——

• 复用 Linux 专属代码
  ：团队里那坨「只能在 Linux 上编译」的祖传代码，不用再单独维护一台构建机；
• 云应用本地化
  ：把云上跑的应用原样搬到本地调试，环境一致；
• 资源隔离
  ：把一个 Linux 进程对宿主资源的访问，整个关进容器里。

更狠的是和 MSBuild、CMake 的集成。项目文件里加几行配置，容器的构建和部署就自动进入你的编译流程，不需要任何手动步骤。

还有个很多人关心的定位问题。传统上 WSL 的官方建议是「仅适合开发测试，不建议生产」。Craig Loewen 在博客评论区明确回复了——WSL 容器 API 将支持生产环境使用。这算是把话说满了。

四、底层三连：文件快 2 倍、新网络模式、内存回收

做容器功能的过程中，微软顺手把 WSL 的底层也翻新了三处，这才是对所有 WSL 用户都有意义的部分。

第一，virtiofs 成为 WSL Containers 的默认文件系统，Windows 文件访问速度直接翻倍。「在 /mnt/c 下面打开一个项目慢到怀疑人生」这个 WSL 老大难，终于有了官方级解法。

第二，新的默认网络模式 consomme（法语「清汤」，微软起名的品味一直在线）。它的思路是把 Linux 的网络流量通过 Windows 侧中继——VPN、代理、企业网络策略这些「WSL 联网玄学」的重灾区，兼容性会明显改善。

第三，内存回收改进。Linux 虚拟机里不再使用的内存，会被逐步、稳定地还给 Windows 宿主机。vmmem 内存占用只涨不降的吐槽，有望缓解。

⚠️ 注意一个细节：这些改动动了文件系统和网络的关键路径，目前只在 WSL Containers 里默认启用，微软计划未来才逐步推广到标准 WSL。

微软也专门表了个态：Docker Desktop、Podman Desktop、Rancher Desktop 这些构建在 WSL 之上的第三方工具，同样会从这批底层改进中受益。翻译一下——微软没想把生态一锅端，它想把水位整体抬高。

五、泼冷水：现在卸载 Docker，还太早

写到这你可能已经心动了。但作为技术号，我们得把另一半事实也摆出来——预览阶段的 WSL Containers，离「替代 Docker」还有实打实的距离。

• docker compose 还不支持
  。这是官方博客评论区被问得最多的问题，Craig Loewen 的回复是「呼声最高的功能，正在调研最佳实现方式」。对跑多容器服务的人来说，这一条就足够劝退了；
• USB 直通还没有
  。--device、--privileged 这些 Docker 里熟悉的参数，wslc 目前找不到对应能力。搞硬件开发板的先观望；
• 部分网络场景有坑
  。有用户反馈容器内访问局域网其他机器正常，访问 Windows 宿主机本机的 Web 服务却不行；
• 生态还在跟进
  。VS Code 的 Dev Containers 已在 0.462.0 预发布版支持 wslc（把「Docker Path」设置改成 wslc 即可），但离全面 GA 还差一步。

所以我们的建议很明确——尝鲜可以，主力工作流先别迁。Docker 在 Windows 上的位置，至少在 2026 年内依然稳固。

六、企业视角：安全和管控都提前想好了

有个容易被个人用户忽略、但对职场开发者很重要的信号——WSL Containers 的企业级配套，是一起发布的。

• 安全监控
  ：Microsoft Defender for Endpoint 的 WSL 插件已扩展支持容器内安全事件的监控，刚在本月转入公开预览；
• 统一管控
  ：通过 GPO/Intune 可以控制组织内允许使用 WSL 发行版还是容器，还能配置镜像仓库白名单——「哪些镜像允许被拉取」这个企业最关心的合规问题，原生就有答案。

这套组合拳的意图很明显：让 IT 部门敢在公司电脑上放开 WSL 容器。企业采用，才是这个功能真正的胜负手。

七、尝鲜指南：三条命令

想上手很简单，PowerShell 里三条命令：

wsl --update --pre-release    # 升级到预发布版（2.9.3 及以上） wsl --shutdown                 # 重启 WSL，关掉再开终端 wslc --version                 # 看到 2.9.3.0 就装好了

然后跑个 hello-world 感受一下。ARM 设备（比如 Surface）实测也能用。

一个彩蛋。Craig Loewen 自己用业余时间写了个 TUI 面板 lazywslc，GitHub 上就能下——微软产品经理亲手做的社区工具，可以感受一下官方对这个功能的态度。

时间表方面，微软给出的说法是2026 年秋天转正（GA）。按这个节奏，它大概率会赶在 Windows 新一轮大版本更新前后。

八、对 Ubuntu 用户意味着什么

我们之前写过，Canonical 副总裁 Jon Seager 预测 WSL 上的 Ubuntu 用户量将反超原生安装——当时不少读者觉得夸张。现在再看微软这个动作，你会发现两家的路数其实是咬合的。

容器是开发工作流的心脏。当 Windows 原生跑 Linux 容器足够好，「Windows 桌面 + Ubuntu 工具链」这个组合的粘性会指数级上升——你在 Windows 上开会写文档，在 Ubuntu 里构建部署，中间不需要任何切换成本。

而这批用户装进 WSL 的第一个发行版，大概率还是 Ubuntu。

一句话总结

WSL Containers 不是要杀死 Docker，而是把「容器」变成 Windows 的基础能力——就像浏览器内置了 PDF 阅读器之后，独立的 PDF 工具依然有人用，但对大多数人来说，不装第三个工具的日子，不远了。

对开发者，2026 年秋天之前的态度可以很简单——拿它当第二套容器工具养着，主力工作流让 Docker 再站最后一班岗。