编程 WSL Containers 深度解析：Windows 原生 Linux 容器来了，Docker Desktop 的真正挑战者

2026-07-03 06:14:12 +0800 CST views 316

WSL Containers 深度解析：Windows 原生 Linux 容器来了，Docker Desktop 的真正挑战者

前言

2026年6月29日，微软 Build 大会的余温还未散去，一个被严重低估的技术公告悄然发布——WSL Containers 公开预览版上线。

对于普通用户来说，这可能只是一个不起眼的"Windows 更新"；但对于整个容器生态来说，这是一个足以改变游戏规则的信号：在 Windows 11 上，无需安装任何第三方工具，就能原生构建、运行和管理 Linux 容器。

这意味着什么？

意味着 Docker Desktop 在 Windows 上的垄断地位，第一次受到了来自操作系统本身的有力挑战。意味着"Linux 优先"的现代开发工作流，第一次被微软以系统级能力完整接纳。意味着数百万 Windows 开发者，终于可以在不启动任何虚拟机或第三方 Runtime 的情况下，直接进入 Linux 容器的工作流。

本文将深入剖析 WSL Containers 的架构设计、命令行工具、API 体系、隔离机制、性能优化，以及它与 Docker Desktop 的正面 PK。读完你会明白：这不是一次版本迭代，而是一场容器战争的序幕。

一、背景：从 WSL 1 到 WSL 2，Windows 为何一直在追 Linux

1.1 Windows 的 Linux 执念

理解 WSL Containers 的意义，需要先理解微软为什么在"让 Windows 拥抱 Linux"这条路上走得如此坚决。

现代软件开发几乎已经全面 Linux 化。构建流水线跑在 Linux CI 节点上，云基础设施基于 Linux 镜像，PyTorch、TensorFlow 等 AI 框架围绕 Linux 构建和优化，甚至 VS Code 的 Remote Development 插件，最先支持的也是 SSH 到 Linux 服务器。Linux 不再只是一个操作系统，它成了现代软件工程的"通用语言"。

对于 Windows 来说，这是一个严峻的人才竞争问题。如果开发者发现必须在 macOS 或 Linux 上才能高效工作，Windows 的开发者生态就会持续失血。WSL（Windows Subsystem for Linux）从 2016 年诞生开始，就是微软应对这一挑战的战略级产品。

1.2 WSL 的演进路径

WSL 1（2016）：通过翻译层（LXSS）将 Linux 系统调用实时翻译为 Windows API。优点是文件系统访问快（直接访问 Windows 文件），缺点是兼容性问题——并非所有 Linux 程序都能完美运行。

WSL 2（2019）：引入真正的 Linux 内核（通过 Hyper-V 虚拟机），彻底解决了系统调用兼容性问题。docker run 能跑了，apt-get install 所有包都正常，GPU 直通（WDDM）也让机器学习工作流在 WSL 里成为可能。WSL 2 解决了"Linux 内核能力"的问题。

WSL Containers（2026）：在 WSL 2 的内核之上，构建完整的 Linux 容器运行时能力，而无需依赖 Docker Desktop。WSL 2 解决了"Linux 体验"的问题，WSL Containers 则解决了"容器工作流"的问题。

这就是微软的完整战略：WSL 1 → WSL 2 → WSL Containers，一步一步系统性地移除开发者离开 Windows 的每一个理由。

二、核心架构：WSL Containers 是如何工作的

2.1 架构概览

WSL Containers 并不是一个独立的产品，而是一组构建在现有 WSL 2 基础设施之上的新功能层。这与部分媒体错误称呼的"WSL 3"完全不同。

微软 WSL 产品经理 Craig Loewen 明确澄清："不存在 WSL 3，WSL Containers 并非 WSL 2 的版本继任者，而是基于现有 WSL 基础设施构建的新功能层。"

从架构层面看，WSL Containers 包含两个核心组件：

┌─────────────────────────────────────────────────────┐
│                  Windows 11                          │
│                                                      │
│  ┌──────────────────────────────────────────────┐   │
│  │         WSL Container API (NuGet)            │   │
│  │    C / C++ / C# 原生应用集成容器能力          │   │
│  └──────────────────────────────────────────────┘   │
│                                                      │
│  ┌──────────────────────────────────────────────┐   │
│  │            wslc.exe / container.exe          │   │
│  │       Linux 容器 CLI 工具（类 Docker 语法）   │   │
│  └──────────────────────────────────────────────┘   │
│                                                      │
│  ┌──────────────────────────────────────────────┐   │
│  │     WSL 2 Linux VM (独立 Hyper-V 虚拟机)      │   │
│  │  ┌─────────────────────────────────────────┐  │   │
│  │  │   Linux Kernel (5.15+ with Container   │  │   │
│  │  │           Support)                       │  │   │
│  │  └─────────────────────────────────────────┘  │   │
│  │                                              │   │
│  │  ┌────────────┐  ┌──────────────────────┐ │   │
│  │  │  Containerd │  │   WSL Container      │ │   │
│  │  │   Runtime   │  │   Manager            │ │   │
│  │  └────────────┘  └──────────────────────┘ │   │
│  │                                              │   │
│  │  ┌────────────────────────────────────────┐ │   │
│  │  │     virtiofs (2x 文件系统性能提升)      │ │   │
│  │  └────────────────────────────────────────┘ │   │
│  └──────────────────────────────────────────────┘   │
│                                                      │
│  ┌──────────────────────────────────────────────┐   │
│  │              Hyper-V 虚拟机管理               │   │
│  │    (独立 VM 隔离，企业级策略控制)              │   │
│  └──────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────┘

2.2 为什么不是 WSL 3

理解这个技术定位非常关键，因为它直接决定了你应该以什么预期来使用这个功能。

WSL Containers 的设计哲学是增量叠加，而非替代：

WSL 2 的所有现有功能完全保留，你仍然可以 wsl -d Ubuntu 启动一个普通的 Linux 环境
容器能力作为额外的功能模块叠加，不影响现有工作流
所有 WSL 2 的更新和改进都会继续推送给普通用户，不安装 WSL Containers 不会有任何负面影响

这种设计让 WSL Containers 的升级风险降至最低——你不需要做破坏性升级，只需要更新到 WSL 2.9.3，然后自然获得容器能力。

2.3 底层改进：virtiofs 文件系统

WSL Containers 还带来了一个重要的底层改进——新的默认文件系统 virtiofs，使 Windows 文件访问速度提升至原来的两倍。

virtiofs 是一种基于 virtio 协议的高速文件系统共享方案，允许 Linux 虚拟机高效访问宿主机（Windows）的文件系统。在此之前，WSL 2 使用的是 9P 协议的文件共享，性能一直是被开发者诟病的痛点。

不过微软也在公告中说明：由于 virtiofs 涉及文件系统和网络等关键路径，目前仅在 WSL 容器中默认启用，计划未来将其逐步推广至标准 WSL。这说明微软对 virtiofs 在大规模生产环境中的稳定性仍在验证中。

三、命令行工具：wslc.exe 深度解析

3.1 安装与初始化

WSL Containers 作为 WSL 2.9.3 预发布版的一部分提供，安装过程极为简洁：

# 第一步：以管理员身份打开 Windows 终端或 PowerShell
# 第二步：更新到预发布版本
wsl --update --pre-release

# 第三步：重启 WSL
wsl --shutdown

# 第四步：关闭并重新打开终端

# 第五步：确认安装成功
wslc --version
# 应输出：2.9.3.0

# 第六步：查看完整命令参考
wslc --help

安装完成后，wslc.exe 会自动添加到 PATH 环境变量中。微软还提供了一个名为 container.exe 的别名，两者在功能上完全等价。

# 两种命令完全等价
wslc --version
container.exe --version

3.2 命令语法：Docker 开发者零成本迁移

WSL Containers 的命令行语法与 Docker 高度相似，这绝非偶然——这是微软有意为之的设计决策：Docker 开发者无需重新学习任何东西。

以下是 WSL Containers 与 Docker CLI 的命令对照：

功能	Docker CLI	wslc CLI
拉取镜像	`docker pull nginx:latest`	`wslc pull nginx:latest`
运行容器	`docker run -it debian:latest bash`	`wslc run -it debian:latest bash`
后台运行	`docker run -d nginx`	`wslc run -d nginx`
列出容器	`docker ps -a`	`wslc ps -a`
连接到运行中容器	`docker attach <container>`	`wslc attach <container>`
构建镜像	`docker build -t myapp .`	`wslc build -t myapp .`
列出镜像	`docker images`	`wslc images`
删除容器	`docker rm <container>`	`wslc rm <container>`
查看日志	`docker logs <container>`	`wslc logs <container>`

3.3 实战演示：构建第一个 WSL 容器

让我们通过一个完整的实战场景来体验 WSL Containers：

场景：构建一个 Linux 文件检查工具容器

首先创建一个容器定义文件（微软在文档中使用 Containerfile，与 Dockerfile 等价）：

# Containerfile - Linux 系统检查工具
FROM python:3.12-slim

# 安装 Linux 工具链
RUN apt-get update && \
    apt-get install -y --no-install-recommends \
    file \
    exiftool \
    binutils \
    bsdmainutils \
    coreutils \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY app.py .

EXPOSE 5000

CMD ["python", "app.py"]

然后构建和运行：

# 构建镜像
wslc build -t my-linux-inspector .

# 后台运行
wslc run -d my-linux-inspector

# 查看运行状态
wslc ps -a

# 查看容器日志
wslc logs my-linux-inspector

# 连接到运行中的容器（交互式）
wslc attach my-linux-inspector

在容器内可以执行 Linux 命令来验证环境：

# 在容器内执行
$ uname -a
Linux ... 5.15.0-microsoft-standard-WSL2+ #1 SMP ... x86_64 Linux

$ python --version
Python 3.12.4

$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"

3.4 容器分离与重连

使用 Ctrl+P, Ctrl+Q 可以从交互式容器分离（与 Docker 完全相同），之后使用 wslc ps -a 可以看到容器的自动生成名称：

CONTAINER ID   IMAGE                    COMMAND    CREATED        STATUS        NAMES
abc123def456   my-linux-inspector       "python..."  2 hours ago   Up           mossy_sawtooth

使用 wslc attach mossy_sawtooth 可以重新连接到同一个容器会话——这意味着你断开连接不会丢失工作状态，完美模拟了 Docker 的 attach 行为。

四、WSL Container API：把 Linux 容器嵌入原生 Windows 应用

4.1 API 架构

WSL Containers 的第二根支柱是 WSL Container API——一个以 NuGet 包形式分发的编程接口，支持 C、C++ 和 C# 语言。

这个 API 的目标用户是 Windows 应用开发者，它允许将 Linux 容器直接嵌入到原生 Windows 应用程序中，完全不需要暴露 Linux 的存在感。

4.2 实际应用场景

微软用 Moonray（一款用于《狂野机器人》等电影的开源 Linux 渲染引擎）演示了这一能力：Moonray 运行在 Windows 可执行文件中，完全看不出 Linux 的存在。用户运行的是标准 Windows .exe 程序，背后却是一个完整的 Linux 容器在工作。

这意味着以下场景第一次在 Windows 上成为可能：

本地 AI 工作负载：在 Windows 应用中调用运行在 Linux 容器内的 CUDA 加速推理服务，而无需安装 WSL 发行版或 Docker Desktop。

容器化测试流水线：Windows 的 CI/CD 系统可以直接启动 Linux 容器来运行测试用例，无需虚拟机或远程 Linux 机器。

Windows 应用内 Linux 数据处理：高性能数据处理管道可以直接在 Windows 应用内嵌入 Linux 容器来处理繁重的计算任务。

4.3 API 使用示例（C#）

以下是 WSL Container API 的典型使用模式（基于微软文档的示意代码）：

using Microsoft.WSL.Containers;

public class ContainerHost
{
    private readonly IWSLContainerService _containerService;

    public ContainerHost()
    {
        // 初始化容器服务
        _containerService = WSLContainerFactory.CreateService();
    }

    public async Task<string> RunInferenceAsync(string modelPath, byte[] inputData)
    {
        // 启动 Linux 容器（自动创建独立的 Hyper-V VM）
        using var container = await _containerService.CreateContainerAsync(new ContainerOptions
        {
            Image = "pytorch/pytorch:2.4.0-cuda12.1-cudnn8-runtime",
            Name = "inference-worker",
            EnableGPU = true,  // CDI GPU 直通
            WorkingDirectory = "/workspace"
        });

        // 在容器内执行推理命令
        var result = await container.ExecAsync(
            "python", "/scripts/inference.py",
            "--model", modelPath
        );

        return result.Output;
    }
}

API 与 MSBuild 和 CMake 构建系统深度集成，只需在项目文件中添加少量配置，容器的构建和部署即可自动融入应用程序的编译流程：

<!-- .csproj 中的 WSL 容器配置 -->
<ItemGroup>
  <WSLContainer Include="ml-inference">
    <Image>python:3.12-slim</Image>
    <Mount Source="$(MSBuildProjectDirectory)" Target="/workspace" />
    <GPU>true</GPU>
  </WSLContainer>
</ItemGroup>

4.4 CDI（容器设备接口）GPU 直通

WSL Containers 通过 CDI（Container Device Interface） 规范支持 GPU 直通，这是一项关键能力。

CDI 是 Linux 容器生态中的标准化设备接入方案，允许容器在运行时发现并使用宿主机上的硬件设备（如 GPU）。在 WSL Containers 中，CDI 让 Linux 容器可以直接调用 Windows 上的 NVIDIA GPU 驱动，运行 CUDA 机器学习流水线：

# 在 WSL 容器中验证 GPU 访问
$ nvidia-smi
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 535.54.03    Driver Version: 535.54.03  CUDA Version: 12.2       |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  NVIDIA GeForce ...  On   | 00000000:01:00.0  On |                  N/A |
+-------------------------------+----------------------+----------------------+

这意味着 PyTorch、TensorFlow 等依赖 CUDA 的 AI 框架，现在可以在 WSL 容器中直接使用 Windows 上的 NVIDIA 显卡进行训练和推理，无需 Docker Desktop，也无需任何额外的驱动配置。

五、隔离机制：Hyper-V 虚拟机 vs Docker Desktop

5.1 隔离模型的根本差异

这是理解 WSL Containers 与 Docker Desktop 区别最关键的地方。

Docker Desktop 的隔离模型：Docker Desktop for Windows 使用 WSL 2 作为后端，所有 Linux 容器运行在单一共享的 WSL 2 虚拟机中。这意味着所有容器共享同一个 Linux 内核实例，容器间通过 cgroups 和 namespace 进行进程级隔离。

Docker Desktop:
┌─────────────────────────────────────────────┐
│         WSL 2 单一共享 VM                    │
│  ┌────────┐  ┌────────┐  ┌────────┐          │
│  │Container│  │Container│  │Container│        │
│  │   A    │  │   B    │  │   C    │          │
│  └────────┘  └────────┘  └────────┘          │
│  共享 Linux Kernel + Containerd Runtime      │
└─────────────────────────────────────────────┘

WSL Containers 的隔离模型：每个调用 WSL Container API 的 Windows 应用程序，或者每个独立的 CLI 容器流程，都会获得独立的 Hyper-V 虚拟机。

WSL Containers:
┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│   Hyper-V    │  │   Hyper-V    │  │   Hyper-V    │
│  VM (App A)  │  │  VM (App B)  │  │  VM (CLI)   │
│ ┌──────────┐ │  │ ┌──────────┐ │  │ ┌──────────┐ │
│ │Container │ │  │ │Container │ │  │ │Container │ │
│ │    A1    │ │  │ │    B1    │ │  │ │    C1    │ │
│ └──────────┘ │  │ └──────────┘ │  │ └──────────┘ │
└──────────────┘  └──────────────┘  └──────────────┘

5.2 各有优劣

Docker Desktop 单一 VM 的优势：

资源效率更高，多个容器共享同一个 Linux 内核，内存开销更小
容器间通信（Docker network）延迟更低
镜像层可以共享，节省磁盘空间

WSL Containers 独立 VM 的优势：

强隔离性：应用程序崩溃不会影响其他容器的运行
企业管理能力：每个 VM 可以独立设置资源限制、安全策略
Windows 审计工具兼容：管理员可以使用标准 Windows 工具查看和监控容器

微软的取舍逻辑：WSL Containers 优先面向企业级应用集成和开发者工具链，强隔离和可管理性优先于极致资源效率。这与 Docker Desktop 面向个人开发者的定位有明显差异。

六、企业级管理：WSL Containers 的安全与合规优势

6.1 与 Windows 管理基础设施的深度集成

WSL Containers 最大的差异化优势，可能不在技术层面，而在企业 IT 管理能力上。

Docker Desktop 虽然在个人开发者中流行，但在大规模企业环境中一直存在管理难题：需要按席位付费（Business 订阅），部署通过 MSI 包而非标准 Windows 管理工具，容器的运行状态和安全审计都游离在 Windows 管理框架之外。

WSL Containers 则完全融入了 Windows 的企业管理体系：

组策略 / MDM 控制：

# IT 管理员可以通过组策略配置
# 限制只能运行经过批准的容器镜像
# 强制要求镜像来源为企业私有仓库
# 禁用未经授权的容器运行

# 示例：通过 MDM 配置策略
# (由 IT 部门统一下发)
Policy: WSLContainerPolicy = {
    AllowedRegistries: ["corp.registry.internal"],
    RequireSignedImages: true,
    MaxContainerMemory: "4GB",
    EnableGPUPassthrough: false
}

Windows 审计工具集成：管理员可以通过标准 Windows 事件查看器和审计工具，直接查看容器的启动记录、资源使用情况和安全事件——这是 Docker Desktop 原生不具备的能力。

资源配额和 QoS：每个 Hyper-V VM 都可以独立设置 CPU、内存、网络带宽的配额，这是 WSL Containers 架构天然支持的，无需额外的配置。

6.2 对企业 AI 工作流的潜在影响

随着 AI 应用在企业中的普及，一个典型场景正在出现：

企业需要在其 Windows 应用（如内部工具、数据分析平台）中集成 AI 推理能力，但这些 AI 模型（如 PyTorch 模型）需要 Linux 环境才能运行。以往的解决方案包括：

要求用户安装 Docker Desktop（IT 管理成本高）
维护远程 Linux 服务器（网络延迟和运维成本）
使用 WSL 2 + 手动配置（体验不一致）

WSL Containers 提供了第四种可能：企业应用直接通过 API 启动隔离的 Linux 容器来运行 AI 工作负载，用户体验是无缝的 Windows 应用，底层是优化过的 Linux + GPU 环境，IT 部门可以通过熟悉的 Windows 工具进行管理。

七、当前局限与未来路线图

7.1 现阶段的功能缺失

微软在发布公告中明确承认，WSL Containers 目前仍缺少以下能力：

Docker Compose 缺失：不支持多服务编排。如果你的应用由多个容器组成（如典型的微服务架构），WSL Containers 目前无法处理。微软表示这是"已在路线图上"的功能。

图形化控制面板：没有 Docker Desktop 那样的 GUI 客户端来查看镜像列表、容器状态、日志流等。所有操作都需要通过命令行或 API。

镜像安全扫描：没有类似 Docker Scout 的漏洞扫描能力。企业安全团队在正式采用前需要自行建立镜像安全审计流程。

完整的 Kubernetes 支持：不支持将 WSL Containers 集群加入 Kubernetes 集群（K8s 需要完整的 kubelet 和 crictl 集成）。这对于需要本地 K8s 开发环境的开发者来说是个限制。

7.2 发布路线图

时间	里程碑
2026年6月	WSL 2.9.3 预发布版，WSL Containers 公开预览
2026年秋季	WSL Containers 正式版发布（GA）
未来版本	Docker Compose 支持（计划中）
未来版本	virtiofs 推广至标准 WSL（计划中）

微软强调，WSL Containers 不要求 Copilot+ PC，但依赖现代虚拟化支持，需在 BIOS 或 UEFI 中启用虚拟化功能（VT-x/AMD-V）。

八、性能对比：WSL Containers vs Docker Desktop vs 传统 VM

8.1 启动速度

WSL Containers 的容器启动速度值得关注。外媒实测，从 wslc run 到容器内命令执行，速度与 Docker Desktop 基本持平，部分场景甚至更快——这得益于 WSL 2 内核经过多年优化后的成熟度。

# 测试容器冷启动时间
$ time wslc run --rm debian:latest echo "ready"

# 对比 Docker Desktop
$ time docker run --rm debian:latest echo "ready"

两者都受益于 WSL 2 内核的预热机制（内核在首次需要时被加载，之后保留在内存中），冷启动时间都可以控制在 1-2 秒内。

8.2 资源占用

WSL Containers 的独特架构（每个 CLI 会话一个 VM）意味着资源占用模式与 Docker Desktop 不同：

单容器场景：WSL Containers 的额外 VM 层会带来少量内存开销（约 50-100MB 的 Hyper-V 最小开销）
多容器场景：WSL Containers 的独立 VM 策略会导致资源占用叠加，但提供了更强的隔离性
virtiofs 文件系统：2 倍的文件系统性能提升是 WSL Containers 的独特优势，对 I/O 密集型工作负载影响显著

8.3 GPU 工作流性能

GPU 直通是 WSL Containers 的亮点之一。通过 CDI 接入 NVIDIA GPU 的延迟与 Docker Desktop 基本相同：

import torch

# 测试 CUDA 访问
print(f"CUDA available: {torch.cuda.is_available()}")  # True
print(f"Device count: {torch.cuda.device_count()}")    # 1
print(f"Device name: {torch.cuda.get_device_name(0)}") # NVIDIA GeForce RTX ...

# 简单张量运算
device = torch.device("cuda:0")
x = torch.randn(1000, 1000, device=device)
y = torch.matmul(x, x)
print(f"Result on: {y.device}")  # cuda:0

在 WSL 容器中运行 PyTorch CUDA 工作流，与在 Docker Desktop 中运行的性能数据完全一致，因为底层都是相同的 WSL 2 + NVIDIA 驱动栈。

九、实战：搭建你的第一个 WSL Containers 开发环境

9.1 环境准备清单

在开始之前，确保满足以下条件：

Windows 11（WSL Containers 不支持 Windows 10）
WSL 2 已安装：wsl --install 或从"启用或关闭 Windows 功能"启用
虚拟化已启用：在 BIOS/UEFI 中启用 VT-x（Intel）或 AMD-V（AMD）
加入 Windows 预览体验计划（Beta 频道），以获取最新 WSL 更新

9.2 完整安装脚本

# ========================================
# WSL Containers 安装脚本（一键执行）
# ========================================

# 1. 检查当前 WSL 状态
Write-Host "检查 WSL 安装状态..." -ForegroundColor Cyan
wsl --status

# 2. 更新到预发布版本（包含 WSL Containers）
Write-Host "`n更新 WSL 到预发布版本..." -ForegroundColor Cyan
wsl --update --pre-release

# 3. 重启 WSL
Write-Host "`n重启 WSL..." -ForegroundColor Cyan
wsl --shutdown

# 4. 验证安装
Write-Host "`n验证 wslc 版本..." -ForegroundColor Cyan
wslc --version

# 5. 拉取第一个测试镜像
Write-Host "`n拉取 Debian 测试镜像..." -ForegroundColor Cyan
wslc pull debian:latest

# 6. 列出镜像
Write-Host "`n当前镜像列表:" -ForegroundColor Cyan
wslc images

Write-Host "`n安装完成！输入 'wslc --help' 查看所有可用命令。" -ForegroundColor Green

9.3 快速验证命令

安装完成后，以下命令可以快速验证所有核心功能：

# 1. 验证 Linux 环境
wslc run --rm debian:latest uname -a

# 2. 验证网络访问
wslc run --rm debian:latest ping -c 3 8.8.8.8

# 3. 验证包管理器
wslc run --rm debian:latest apt-get update && \
    apt-get install -y curl && \
    curl --version

# 4. 验证 Python 环境
wslc run --rm python:3.12-slim python --version

# 5. 验证 GPU 访问（需要 NVIDIA GPU）
wslc run --rm --gpus all nvidia/cuda:12.1.0-base-ubuntu22.04 nvidia-smi

9.4 一个实用的开发工作流示例

假设你在 Windows 上开发一个 Python 数据处理工具，需要在 Linux 环境中进行测试：

# 1. 创建项目目录
mkdir C:\my-project
cd C:\my-project

# 2. 编写项目文件
# main.py
# requirements.txt

# 3. 构建测试容器
wslc build -t my-project:test .

# 4. 运行测试
wslc run --rm \
    -v "$(pwd):/app" \
    my-project:test \
    pytest /app/tests/

# 5. 进入开发模式（交互式）
wslc run -it \
    -v "$(pwd):/app" \
    -w /app \
    my-project:test \
    bash

# 6. 发布前构建生产镜像
wslc build -t my-project:prod --target production -t my-project:prod .

十、深度思考：WSL Containers 对生态的影响

10.1 Docker Desktop 的定价困境

Docker Desktop 的商业化策略一直是开发者社区的争议焦点。2021年，Docker 修改服务协议，要求大型企业必须付费订阅。2023年，Docker Business 订阅价格继续上涨。这让很多中型企业开始寻找替代方案。

WSL Containers 的出现正好填补了这个空白：免费、原生、无订阅，并且与 Windows 11 的企业管理体系天然集成。对于那些"因为不想付 Docker Desktop 订阅费而犹豫上容器"的企业来说，这可能是一个决定性的转折点。

10.2 微软的生态闭环战略

如果我们把视角拉高一点，会发现微软的布局远比"一个容器工具"更有野心：

Coreutils for Windows（Build 2026 同期发布）：用 Rust 编写的 75+ 个 Linux 命令行工具，无需 WSL 或虚拟机即可在 Windows 上直接运行
Intelligent Terminal（实验性功能）：将 AI 辅助能力直接集成到终端中
WSL 2：完整的 Linux 内核支持
WSL Containers：原生容器运行时
Windows Terminal：现代化的终端体验

微软正在构建一个完整的"Windows 原生 Linux 开发栈"，让开发者可以在不离开 Windows 的情况下完成所有 Linux 环境下的工作。如果这个生态闭环成功，开发者留在 Windows 的理由将大大增加——这对 macOS 和原生 Linux 的开发者生态是一个直接挑战。

10.3 对 DevOps 和 CI/CD 的影响

WSL Containers 还可能改变 Windows 上的 CI/CD 工作流：

传统方案（使用 Docker Desktop）：

# .github/workflows/ci.yml
jobs:
  test:
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install Docker Desktop
        run: |
          # Docker Desktop 安装通常需要几分钟
          # 并且需要重启 runner
      - name: Build and test
        run: |
          docker build -t myapp .
          docker run myapp pytest

WSL Containers 方案：

# .github/workflows/ci.yml
jobs:
  test:
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v4
      - name: Update WSL
        run: wsl --update --pre-release
      - name: Build and test
        run: |
          wslc pull python:3.12-slim
          wslc build -t myapp .
          wslc run --rm myapp pytest

安装步骤从"下载和配置 Docker Desktop"变成了"更新 WSL"，构建时间大幅缩短。不过需要注意：GitHub Actions 的 Windows runner 目前可能还没有预装 WSL Containers，需要等待平台支持。

10.4 容器战争的下一幕

WSL Containers 的出现，让容器生态的竞争格局发生了微妙的变化：

Docker：继续保持桌面端开发者体验的领先，Docker Desktop 的 GUI、Compose、Docker Hub 生态仍有优势
Podman：WSL Containers 对 Podman 的 Windows 支持策略有潜在影响——Podman Desktop 原本是 Docker Desktop 的主要替代品，现在面临系统原生方案的竞争
containerd / runc：WSL Containers 的容器运行时基于 containerd，这意味着 Linux 容器标准在 Windows 上的实现又前进了一步

可以预见的是，随着 WSL Containers 正式版在 2026 年秋季发布，Docker 公司必将做出回应——无论是降价、推出新功能，还是加速 Windows 原生集成的研发。这场容器战争的下一幕，将比过去几年精彩得多。

十一、总结：Windows 开发者的容器新纪元

WSL Containers 的发布，是微软送给 Windows 开发者的一份重磅礼物——不是"又一个功能更新"，而是系统级地重构了 Windows 上的 Linux 开发体验。

核心要点回顾

无需 Docker Desktop：WSL Containers 让 Windows 11 原生支持 Linux 容器，无需安装任何第三方工具
零学习成本：命令行与 Docker 高度相似，Docker 开发者可以无缝迁移
企业级能力：与 Windows 组策略、MDM、审计工具的深度集成，解决了 Docker Desktop 的企业管理痛点
GPU 直通：通过 CDI 规范支持 CUDA 工作流，AI 开发者可以在 WSL 容器中直接使用 NVIDIA 显卡
架构创新：每个应用/CLI 会话独立 Hyper-V VM，提供比 Docker Desktop 更强的隔离性
性能改进：virtiofs 文件系统使文件 I/O 性能提升 2 倍

局限与风险

目前处于公开预览阶段，生产环境建议等待秋季正式版
尚不支持 Docker Compose，多服务编排需要额外工具
独立 VM 架构在多容器场景下资源开销高于 Docker Desktop
GitHub Actions 等 CI/CD 平台尚未全面支持

给不同开发者群体的建议

个人开发者：如果你是 Docker Desktop 用户，现在可以开始尝鲜 WSL Containers 预览版。建议保持两者并存，先在不重要的项目中验证兼容性。如果一切正常，Docker Desktop 的订阅费可以考虑省下来了。

企业开发者：WSL Containers 的企业集成能力值得关注。建议在正式版发布后评估，尤其是在 Windows 应用内嵌 AI 工作负载的场景上。但目前不建议在生产环境中使用预览版。

DevOps 工程师：关注 Docker Compose 支持的进展和 CI/CD 平台的适配情况。如果 Docker Compose 很快得到支持，WSL Containers 将成为 Windows CI/CD runner 的有力选择。

最后一句话：微软正在系统性地实现"Windows 是运行 Linux 工作负载最便捷的平台"这个目标。WSL Containers 是这条路上的关键一步。无论你是 Docker 的拥趸还是观望者，这场容器变革都值得你保持关注。

毕竟，当操作系统本身开始做开发工具的时候，没人能忽视它的力量。