WSL 3.0 容器：微软对 Docker 领地的一次进攻

微软希望你忘记 Docker Desktop 的存在

微软于 9 月 29 日宣布 WSL 3.0 正式发售，其头条功能并非内核微调或文件系统升级，而是容器。

微软现在将 Windows Subsystem for Linux 定位为完整的容器运行时，直接与 Docker Desktop 正面竞争——后者是大多数 Windows 开发者在需要 Linux 容器时的首选工具。经过今年 6 月开始的公开预览后，--pre-release 标志已移除。运行 wsl --update 或从 GitHub 获取发行版，即可在 WSL 内运行一个可用的容器引擎。

这并非渐进式改进，而是一次战略重新定位。

这对 Windows 开发者为何重要

多年来，在 Windows 上运行容器意味着安装 Docker Desktop，如果组织规模超过席位门槛则需购买 Pro 授权，并忍受 Hyper-V 或 WSL 2 后端——这种方案偶尔会让你感觉离想要模拟的 Linux 工具链总是隔着一层。

WSL 容器消除了这一差距。运行时直接内嵌于 WSL 本身，无需单独管理 Docker 守护进程，没有授权门槛，容器与主机之间也不存在虚拟机层。命令行界面（wslc.exe）及其别名（container.exe）暴露的命令与 Docker 接口高度一致：build、run、restart、cp、network connect/disconnect、health checks、events streaming。

通过 Microsoft.WSL.Containers NuGet 包还提供 API 层，支持 C、C++ 和 C#。文件挂载、GPU 访问、标准 I/O——全部可编程。开发 Windows 原生工具并需要编排 Linux 容器的开发者，不再需要调用 Docker Desktop 的 CLI 或 REST API。

命令集较预览版已有扩展。wslc system info 可展示环境状态。wslc events 以实时流方式推送容器活动。网络可使用自定义驱动选项创建。容器现已支持 --stop-timeout（包含 -1 值以启用无限宽限期）和 --mount。默认的 wslc 会话允许你指定哪个驱动器承载容器存储——当你跨多个卷运行镜像时，这一实用细节尤为重要。

彰显诚意攻势的企业级功能

微软不仅在争取个人开发者，企业路线才是可能扭转局势的关键。

两项新的 Microsoft Intune 策略赋予 IT 部门控制权：一项管控 WSL 容器是否可以运行，另一项限制镜像可从哪些容器注册表拉取。对于长期难以执行 Docker Desktop 授权或规范容器镜像来源的组织而言，这是一个更清晰的管控模型。

Microsoft Defender for Endpoint 现已具备 WSL 插件，可追踪容器进程、文件操作和网络活动，并将其与主机侧事件关联。安全团队无需部署独立的容器监控栈即可获得可见性。这对重度依赖 Windows 的企业而言，意味着工具泛滥的显著缓解。

日本开发者社区已在测试

WSL 容器的最初报道源自日本科技媒体，那里的采用信号值得注意。日本开发工作室——尤其是游戏和嵌入式系统领域——历来依赖 Docker Desktop 进行跨平台容器工作流。授权成本和维护独立 Linux VM 栈的开销一直是持续的摩擦点。

社区工具已经出现。Lazywslc 和 WSL Container Desktop 正由志愿者构建。Aspire（开源 ASP.NET Core 应用模板）现已将 WSL 容器列为支持的运行时。VS Code 的 Container Tools 扩展已添加支持，VS Code 的 Dev Containers 现在可将 wslc 指定为默认驱动。

用户呼声最高的功能——wslc compose——尚未发布。微软表示这是其首要优先级。Docker Compose 兼容性是大多数团队实现平滑迁移与重写本地开发工作流之间唯一的鸿沟。

超越容器的性能升级

WSL 3.0 包含两项基础设施改进，不仅惠及容器，也惠及所有在 WSL 内运行的工作负载。

Virtiofs 取代了旧版 Plan 9 文件系统共享。微软报告跨操作系统文件访问吞吐量提升约一倍。对于读写大量文件的容器——构建产物、数据库转储、日志轮转——这是切实的性能提升，而非基准测试中的猎奇数据。

Consomme 将 Linux VM 的网络流量重新路由至用户态 Windows 进程，而非经由虚拟网络栈处理。其效果是更好地兼容 VPN 和 Windows 防火墙——这些工具长期以来一直是 Windows 上运行容器开发者的痛点。

这些升级将使 WSL 发行版及其他在 WSL 之上运行的容器平台受益，而不仅是新的原生运行时。

Docker 失去什么

在这场变革中，明确的输家是 Docker Desktop 在 Windows 上的差异化优势。该产品最强的卖点从来不是技术本身，而是便利性——安装它，容器就能直接运行。

WSL 容器提供同等便利性且零授权成本，具备更深的 Windows 集成和第三方守护进程。Docker Desktop 在跨平台一致性、成熟的 Compose 实现以及围绕其 API 构建的大量现有工具方面仍占优势。但如果 wslc compose 发布并实现兼容，这些优势将迅速缩水。

对于已为 Docker Pro 或 Business 授权付费的组织，WSL 容器提供了一条削减开支的路径。对于新团队，它提供了一个完全跳过 Docker Desktop 的理由。

接下来会发生什么

关键问题是微软需要多长时间才能推出 wslc compose，以及它与 Docker Compose 的兼容程度如何。Compose 是维系大多数本地开发工作流的粘合剂。没有它，WSL 容器只是一个运行时——有用但不完整，对依赖 YAML 定义的多服务栈的团队尤其如此。

微软在过去三年中于开发者工具领域的表现已有显著改善。收购 VS Code、并购 GitHub、投资 Linux 上的 .NET——都表明这是一家认真对待开发者体验的公司。WSL 容器符合这一模式。

尚不明确的是，微软是否会为生态系统开放足够多的 API，让生态围绕其构建，就像 Docker 当年那样。NuGet 包和 CLI 只是起点。但容器工具生态依赖于扩展、插件和集成——这些需要开放的接口，而不仅仅是文档完善的接口。

目前，想要 Linux 容器的 Windows 开发者首次拥有了一个可信的原生选项。它能否成为默认选择，取决于接下来还有什么会发布。