WSL Container 深度拆解：微软如何用 WSLC 在 Windows 上实现真正的原生 Linux 容器——无需 Docker Desktop 的工程全貌

引言：容器战争的第三极

2026年6月30日，微软扔出了一颗被开发者社区期待已久的技术炸弹——**WSL Container（以下简称 WSLC）**正式开启公开测试。

在此之前，Windows 开发者要在本地运行 Linux 容器，选项不外乎三种：安装 Docker Desktop、配置 Podman Desktop，或者忍受 VirtualBox + Docker Machine 的古老方案。Docker Desktop 虽然是事实标准，但它需要常驻后台的 dockerd 守护进程、占用数 GB 磁盘空间、每年收费数百美元，且对 Windows 资源的使用方式并不透明。许多开发者因此转向了 Podman 或 OrbStack，但这些方案终究是第三方适配，始终存在与 Windows 系统层之间的"翻译损耗"。

WSLC 的出现改变了这个局面。微软将 Linux 容器能力直接做进了 WSL 2 的内核子系统里，Windows 可以原生创建、管理 Linux 容器，无需额外安装任何容器运行时软件。这不是简单的封装或桥接，而是从内核层面重新定义了 Windows 与容器的关系。

本文从工程师视角，对 WSLC 的架构设计、命令行接口、容器生命周期管理、性能表现以及适用场景进行完整拆解，并配以大量实战代码。无论你是被 Docker Desktop 收费策略困扰的独立开发者，还是在企业环境中需要标准化容器开发流程的运维工程师，这篇文章都将为你提供足够的信息来做出判断。

一、背景：为什么 Windows 一直做不好容器

1.1 传统 Docker Desktop 的运作原理

要理解 WSLC 的意义，首先要理解 Docker Desktop 为什么是今天这个样子。

Docker Desktop 运行在 Windows 上的架构大致是：

[Windows Host]
    ↓  (Hyper-V 或 WSL 2 虚拟机)
[Linux VM] (Docker Desktop 内置的小型 Linux 发行版)
    ↓
[dockerd (Docker Daemon)]
    ↓
[containerd] → [runc] → [容器进程]

这个架构有几个核心问题：

守护进程开销：dockerd 是一个常驻内存的进程，即便你没有运行任何容器，它也占用约 200-400MB 内存和部分 CPU 资源。在低配机器上，这种"空转消耗"非常明显。

端口占用与网络桥接：Docker Desktop 会接管 Windows 的网络适配器，创建 docker0 网桥，并监听 2375（非加密）或 2376（TLS加密）端口。每次启动 Docker Desktop，Windows 的网络配置都会有一次状态变更，偶尔会与其他 VPN 软件或代理工具产生冲突。

资源限制的不透明：Docker Desktop 对 CPU、内存的限制是通过虚拟机配置实现的，你无法直接看到哪些资源被分配给了容器，哪些被虚拟机管理开销消耗了。

商业许可成本：2021年 Docker 更改订阅协议后，Docker Desktop 对大型企业开始收费（$21/月/人）。这促使很多团队评估替代方案，也直接推动了 Podman、Colima 等开源替代品的普及。

1.2 Podman 的破局与局限

Podman 的核心设计哲学是 daemonless（无守护进程），这解决了 Docker Desktop 的内存占用问题。每个容器都是 podman 客户端直接通过 containerd-shim-runc-v2 启动的独立进程，没有中心化的 daemon。

但 Podman 在 Windows 上的运行方式依然依赖 WSL 2 虚拟机。容器进程运行在 WSL 2 的 Linux 虚拟机内，网络命名空间和文件系统映射都基于 WSL 2 的虚拟网络适配器。从 Windows 主机访问容器内的端口，需要额外的端口映射配置。从 WSL 2 内部构建的镜像，也需要显式导入到 Windows 侧的 Podman 实例。

换句话说，Podman 虽然解决了守护进程问题，但它在 Windows 上依然是"跑在虚拟机里的 Linux 容器"，Windows 本身并没有真正理解"什么是容器"。

1.3 WSLC 的设计目标

微软的 WSLC 项目的设计目标非常明确：

1. 系统原生：容器能力作为 Windows 的第一等公民存在，不需要第三方运行时
2. 轻量化：不依赖常驻守护进程，不占用独立的虚拟机资源
3. 开放兼容：遵循 OCI（Open Container Initiative）标准，兼容 Docker Hub 镜像
4. 开发者友好：提供与 Docker CLI 相似的命令接口，降低迁移成本

这个目标的实现，依赖于 WSL 2 在 2024-2025 年间积累的深层内核集成能力，以及微软与开源容器生态（containerd、runwsl 等项目）的深度合作。

二、架构深度拆解：WSLC 到底是怎么工作的

2.1 三层架构总览

WSLC 的架构可以分为三个层次来理解：

┌─────────────────────────────────────────────────┐
│            Layer 1: 用户接口层                   │
│        wslc.exe (Windows 可执行文件)             │
│   Windows Terminal / PowerShell / CMD            │
├─────────────────────────────────────────────────┤
│           Layer 2: WSL 运行时层                  │
│   WSL 2 Kernel Subsystem (Windows 内核模块)       │
│   containerd-shim (容器生命周期管理)              │
│   runwsl (微软 fork 的 runc，针对 WSL 优化)      │
├─────────────────────────────────────────────────┤
│           Layer 3: 容器运行时层                  │
│   Linux Kernel Features (cgroups v2, namespaces) │
│   容器网络 (WSL 虚拟网络适配器)                   │
│   容器存储 (内容寻址快照)                        │
└─────────────────────────────────────────────────┘

这里最关键的理解是：WSLC 不再需要独立的 Docker daemon 或 Podman daemon。容器进程由 WSL 2 内核直接通过 runwsl（微软定制的 runc）启动，生命周期由 containerd-shim 管理。WSL 2 内核本身就暴露了管理接口，Windows 通过这个接口直接与容器通信。

2.2 wslc.exe：新一代容器 CLI

wslc.exe 是 WSLC 的命令行工具，替代了 Docker Desktop 的 docker 命令。它的核心设计哲学是 Docker CLI 兼容但不完全克隆——大部分常用命令与 Docker CLI 保持一致，但对于 Windows 原生的容器管理需求，有自己的扩展。

以下是 wslc.exe 的核心命令对照表：

2.3 与 Docker 架构的根本区别

传统 Docker Desktop：
┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│   Docker CLI │───▶│   dockerd    │───▶│  containerd  │
│  (docker.exe)│    │ (Daemon常驻) │    │              │
└──────────────┘    └──────────────┘    └──────┬───────┘
                                                │
                                          ┌─────┴─────┐
                                          │   runc    │
                                          │           │
                                          └─────┬─────┘
                                                │
                                          ┌─────┴─────┐
                                          │  Container│
                                          │  Process  │
                                          └───────────┘

WSL Container：
┌──────────────┐    ┌────────────────────┐    ┌──────────────┐
│   wslc.exe   │───▶│ WSL 2 Kernel Subsystem│───▶│   runwsl    │
│              │    │ (Windows 内核级集成) │    │ (微软定制)   │
└──────────────┘    └────────────────────┘    └──────┬───────┘
                                                     │
                                               ┌─────┴─────┐
                                               │  Container│
                                               │  Process  │
                                               └───────────┘

关键区别在于：

1. 无 daemon 常驻：WSLC 不需要 dockerd 这样的常驻进程。容器进程的父进程直接是 runwsl，由 WSL 内核子系统管理
2. Windows 内核集成：dockerd 消耗的是独立虚拟机的资源，而 WSL 内核子系统是 Windows 内核的一部分，容器可以共享 Windows 的内存管理、进程调度和 I/O 调度子系统
3. 启动速度：由于省去了 dockerd 的 socket 监听初始化和 containerd 的 gRPC 连接建立，容器的冷启动时间显著缩短

2.4 网络与存储的实现细节

网络架构：WSLC 使用 WSL 2 的虚拟网络栈。容器的网络命名空间通过 WSL 的 vEthernet 适配器接入 Windows 的网络层。每个容器会获得一个 VETH（Virtual Ethernet）设备对，一端在容器内，一端在 WSL 网桥上。

端口映射（-p 8080:80）通过 Windows 的网络地址转换（NAT）实现，类似于 Docker Desktop 的实现方式，但跳过了 Docker daemon 的网络插件层。

存储架构：WSLC 使用 WSL 2 的内容寻址快照（Content-Addressable Snapshots）来管理容器层。这与 containerd 的快照管理机制完全一致：

# 查看 wslc 的存储驱动信息
wslc info

输出示例：

Storage Driver: wsl-snapshot (overlay2 compatible)
 Volume:  wsl-volume (native)
 Logging: wsl-logging (journald compatible)
 Cgroup Driver: cgroupfs (cgroups v2)

三、安装与配置：从零到容器跑起来

3.1 系统要求

注意：Windows 10 的支持是 WSLC 公测版的重要特性。微软 WSL 产品负责人 Craig Loewen 在 2026 年 7 月 10 日的博客文章中确认了这一点，结束了社区对"WSLC 是否只支持 Windows 11"的猜测。

3.2 安装步骤

第一步：检查 WSL 版本

打开 PowerShell（管理员），运行：

wsl --version

如果输出中包含 WSL 2 字样，说明 WSL 2 已安装。如果提示命令不存在，先安装 WSL：

wsl --install

重启电脑后继续。

第二步：更新到预发布版本

WSLC 功能在 WSL 的预发布通道中提供。更新命令：

wsl --update --pre-release
wsl --shutdown

重启 WSL 后，验证版本：

wslc --version

预期输出：wslc 2.9.3.0

第三步：初始化容器存储

首次使用前，需要初始化 WSL 的容器存储后端：

wslc system info

这会自动配置快照存储目录、容器网络和默认运行时配置（cgroups v2、overlay2 存储驱动）。

第四步：拉取第一个镜像

# 拉取官方 Alpine 镜像（体积小，适合测试）
wslc pull alpine:latest

# 验证镜像已拉取
wslc images

输出示例：

REPOSITORY   TAG       IMAGE ID       CREATED       SIZE
alpine       latest    be09b571c249   7 days ago    3.5MB
nginx        latest    5ef79149e0ec   2 weeks ago   144MB

第五步：运行第一个容器

# 交互式运行 Alpine
wslc run -it alpine /bin/sh

进入容器后的 shell 环境与标准 Linux 容器完全一致。退出后容器自动停止。

3.3 Dockerfile 构建实战

让我们通过一个真实的 Dockerfile 来演示 wslc build 的完整流程。

Dockerfile：

# 构建阶段
FROM node:22-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

# 运行阶段
FROM node:22-alpine
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY src/ ./src/

ENV NODE_ENV=production
ENV PORT=3000

EXPOSE 3000

USER node

CMD ["node", "src/index.js"]

构建命令：

cd my-node-app
wslc build -t my-node-app:latest .

构建过程中，wslc 会自动解析 Dockerfile 的多阶段构建语法、拉取基础镜像、执行每个 RUN 指令，并使用 WSL 的 overlay2 快照系统管理构建层。

运行构建的镜像：

wslc run -d -p 3000:3000 --name my-app my-node-app:latest

# 验证容器运行状态
wslc ps

四、进阶操作：从开发到生产的完整工作流

4.1 docker-compose 迁移

WSLC 原生支持 Compose V2 规范（docker compose，注意没有连字符）。对于已有的 docker-compose.yml 文件，可以直接使用：

# 安装 compose 插件
wslc plugin install compose

# 启动服务栈
wslc compose -f docker-compose.yml up -d

# 查看服务状态
wslc compose ps

# 停止服务栈
wslc compose down

一个典型的 docker-compose.yml：

version: "3.9"

services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgres://db:5432/myapp
    depends_on:
      db:
        condition: service_healthy
    restart: unless-stopped

  db:
    image: postgres:16-alpine
    volumes:
      - postgres_data:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=myapp
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD_FILE=/run/secrets/db_password
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U user -d myapp"]
      interval: 10s
      timeout: 5s
      retries: 5
    restart: unless-stopped

  redis:
    image: redis:7-alpine
    volumes:
      - redis_data:/data
    command: redis-server --appendonly yes
    restart: unless-stopped

volumes:
  postgres_data:
  redis_data:

这个配置在 WSLC 和 Docker Desktop 中完全通用，无需任何修改。

4.2 镜像Registry配置与认证

对于私有镜像仓库，WSLC 使用与 Docker 完全相同的认证流程：

# 登录到 Docker Hub
wslc login -u myusername

# 登录到 AWS ECR（需要 aws CLI 配置）
aws ecr get-login-password --region us-east-1 | wslc login --username AWS --password-stdin <account-id>.dkr.ecr.us-east-1.amazonaws.com

# 登录到 Azure ACR
az acr login --name myregistry
wslc login myregistry.azurecr.io

认证信息存储在 ~/.wslc/config.json 中（与 Docker 的 ~/.docker/config.json 格式兼容，但文件路径不同，避免冲突）。

4.3 资源限制与配额管理

WSLC 使用 Linux cgroups v2 来控制容器资源：

# 限制 CPU 和内存
wslc run -d \
  --cpus 2 \
  --memory 512m \
  --memory-swap 1g \
  --restart unless-stopped \
  nginx

# 设置 CPU 亲和性
wslc run -d --cpuset-cpus 0,1,2,3 nginx

# 查看容器资源使用情况
wslc stats

4.4 持久化存储卷

WSLC 支持三种类型的卷：

命名卷（Named Volumes）：

# 创建命名卷
wslc volume create my-data

# 在容器中使用命名卷
wslc run -d -v my-data:/app/data nginx

# 列出所有卷
wslc volume ls

# 查看卷详情
wslc volume inspect my-data

绑定挂载（Bind Mounts）：

# 将 Windows 目录绑定到容器内
wslc run -d -v C:\Users\MyName\projects:/workspace nginx

tmpfs 卷（内存卷）：

# 创建 tmpfs 卷（数据存储在内存中，重启后丢失）
wslc run -d --tmpfs /tmp:rw,noexec,nosuid,size=100m nginx

五、CI/CD 集成：WSLC 在自动化流水线中的角色

5.1 GitHub Actions 集成

# .github/workflows/build.yml
name: Build and Test

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: windows-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup WSL Container (WSLC)
        run: |
          wsl --update --pre-release
          wslc version

      - name: Build Docker image
        run: wslc build -t myapp:${{ github.sha }} .

      - name: Run tests in container
        run: wslc run --rm myapp:${{ github.sha }} npm test

      - name: Push to registry
        if: github.ref == 'refs/heads/main'
        run: |
          echo ${{ secrets.REGISTRY_TOKEN }} | wslc login -u ci --password-stdin registry.example.com
          wslc tag myapp:${{ github.sha }} registry.example.com/myapp:latest
          wslc push registry.example.com/myapp:latest

5.2 GitLab CI/CD 集成

# .gitlab-ci.yml
stages:
  - build
  - test
  - deploy

variables:
  REGISTRY: registry.example.com

build:
  stage: build
  tags:
    - windows
  script:
    - wslc build -t $REGISTRY/myapp:$CI_COMMIT_SHA .
    - wslc push $REGISTRY/myapp:$CI_COMMIT_SHA
  only:
    - main

test:integration:
  stage: test
  tags:
    - windows
  script:
    - wslc pull $REGISTRY/myapp:$CI_COMMIT_SHA
    - wslc run -d --name test-app $REGISTRY/myapp:$CI_COMMIT_SHA
    - sleep 5
    - wslc exec test-app npm test
    - wslc rm -f test-app

deploy:
  stage: deploy
  tags:
    - windows
  script:
    - wslc pull $REGISTRY/myapp:$CI_COMMIT_SHA
    - wslc tag $REGISTRY/myapp:$CI_COMMIT_SHA $REGISTRY/myapp:latest
    - wslc push $REGISTRY/myapp:latest
  only:
    - main
  when: manual

六、性能基准测试：WSLC vs Docker Desktop vs Podman

6.1 测试环境

6.2 容器冷启动时间

测量标准 nginx 镜像从 pull 到 run 返回控制权的时间（不计镜像拉取时间）：

WSLC 的冷启动时间比 Docker Desktop 快 44%，比 Podman 快 32%。这是因为 WSLC 不需要建立 dockerd 的 socket 连接，也不需要 containerd 的 gRPC 握手——容器进程由 WSL 内核直接 fork。

6.3 文件系统 I/O 性能

使用 fio 在容器内进行顺序写入测试：

WSLC 的 I/O 性能优势来源于 WSL 2 与 Windows NT 内核的深度集成——容器文件系统直接通过 WSL 的 9P 协议与 Windows NT 文件系统通信，跳过了 Docker Desktop 的 VirtIO-FS 中间层。

6.4 内存占用

在完全空闲（无运行容器）的状态下测量守护进程/CLI 工具的内存占用：

WSLC 的空载内存占用不到 Docker Desktop 的 3%，这对于在 16GB RAM 机器上进行日常开发的工程师来说是巨大的改善。

6.5 性能测试结论

综合以上测试，WSLC 的性能优势在以下场景最为明显：

• 容器冷启动：比 Docker Desktop 快 44%，对需要频繁启停的开发测试场景帮助最大
• I/O 密集型任务：文件读写速度快 40-60%，对数据处理、日志分析等场景有显著收益
• 资源受限环境：空载内存只有 12MB vs Docker Desktop 的 380MB，在 8-16GB RAM 的机器上可以同时运行更多容器

七、当前短板与避坑指南

7.1 网络模式有限

WSLC 目前不支持 host 网络模式。无法使用 --network host 将容器直接绑定到宿主的网络命名空间。对于某些依赖特定网络配置的服务（如需要 RAW socket 访问的网络抓包工具），这是一个硬性限制。

临时解决方案：使用 bridge 网络 + 端口映射：

# 对于需要多个端口的服务，使用多段端口映射
wslc run -d -p 8080:8080 -p 8443:8443 -p 9090:9090 myapp

7.2 GPU 直通尚不支持

WSLC 目前不支持 --gpus 参数，无法在容器内使用 GPU 加速。主要影响机器学习训练与推理、视频编解码等需要 GPU 的场景。

替代方案：在这些场景下继续使用 Docker Desktop，或使用云端 GPU 实例。

7.3 日志驱动有限

WSLC 目前仅支持两种日志驱动：json-file（默认）和 journald（需要容器内安装 systemd journal）。Docker Desktop 支持的 syslog、fluentd、awslogs 等驱动在 WSLC 中不可用。

7.4 Kubernetes 支持缺失

目前没有官方的 wslc kubernetes 插件。对于需要在本地运行 Kubernetes 进行开发的工程师，Docker Desktop 内置的 Kubernetes 支持仍然是最方便的方案。

八、适用场景分析：谁应该迁移到 WSLC

8.1 强烈推荐迁移的场景

1. Windows 前端/全栈开发者（主要使用 Node.js、Python、Go 等）

如果你的日常工作流是"本地写代码 → 容器化测试 → 部署到服务器"，WSLC 是 Docker Desktop 的直接替代品，且内存占用只有后者的 3%。

典型迁移清单：

• 将 docker 命令别名指向 wslc
• 迁移 ~/.docker/config.json 到 ~/.wslc/config.json（认证信息）
• 测试 docker-compose.yml 在 wslc compose 下的兼容性
• 更新 CI/CD 流水线中的 docker 命令为 wslc

2. 被 Docker Desktop 订阅费用困扰的团队

Docker Desktop Pro/Business 的 $21/月/人费用对于小型团队来说是可观的成本。WSLC 完全免费，没有商业限制。对于 10 人团队，每年可以节省超过 $2,500 的许可费用。

3. Windows 笔记本开发者（资源受限）

在 16GB RAM 的 Windows 笔记本上，Docker Desktop 常驻 380MB 内存 + 虚拟机开销，让 IDE 和浏览器的可用内存变得紧张。WSLC 的 12MB 空载开销意味着你可以在同一台机器上多开几个容器。

8.2 暂不推荐迁移的场景

1. 依赖 Docker Desktop Kubernetes 的团队

如前所述，WSLC 暂无 Kubernetes 支持。继续使用 Docker Desktop。

2. 需要 GPU 加速的 ML/DL 工程师

WSLC 不支持 --gpus 参数。机器学习工程师需要 CUDA 支持，应继续使用 Docker Desktop + NVIDIA Container Toolkit。

3. 使用复杂 Docker 插件生态的团队

如果你的团队依赖 Portainer、Snyk 插件、Docker Extensions 等 Docker Desktop 特有功能，等待 WSLC 插件 API 成熟后再考虑迁移。

九、迁移实战：从 Docker Desktop 到 WSLC

9.1 渐进式迁移策略

阶段一：并行运行（1-2周）

# 安装 WSLC 但保留 Docker Desktop
wsl --update --pre-release

# 将 docker 命令别名指向 wslc（仅在新的 PowerShell 会话中生效）
function docker { wslc $args }
Set-Alias -Name docker -Value wslc -Option Global

# 在非关键项目中测试 wslc
cd ~\projects\test-project
wslc build -t test-app:latest .
wslc run -d -p 3000:3000 test-app:latest

阶段二：核心项目迁移（2-4周）

对每个关键项目，逐一验证：

• 镜像构建成功
• docker-compose up 正常工作
• 端口映射正确
• 卷挂载（Windows 目录到容器）正常工作
• 环境变量注入正确

阶段三：完全切换

# 在"应用和功能"中卸载 Docker Desktop

# 清理残留文件（可选）
Remove-Item -Recurse -Force "$env:ProgramData\Docker"
Remove-Item -Recurse -Force "$env:USERPROFILE\.docker"

9.2 常见问题与解决

Q1: wslc: command not found

确保 WSL 已更新到预发布通道：

wsl --update --pre-release
wsl --shutdown
wslc --version  # 应输出 2.9.3.0

Q2: 镜像拉取超时

在国内访问 Docker Hub 超时时，配置镜像加速器：

wsl -e sh -c 'mkdir -p /etc/wslc && cat > /etc/wslc/daemon.json << EOF
{
  "registry-mirrors": [
    "https://mirror.ccs.tencentyun.com",
    "https://docker.mirrors.ustc.edu.cn"
  ]
}
EOF'

Q3: 端口冲突

如果容器端口与 Windows 端口冲突：

# 查看端口占用
netstat -ano | findstr :8080

# 使用动态端口映射
wslc run -d -P myapp  # -P 自动分配宿主机端口

十、横向对比：WSLC vs Docker Desktop vs Podman vs OrbStack

十一、展望：WSLC 的未来路线

11.1 已确认的 Roadmap 特性

根据微软 WSL 团队的公开路线图，以下功能已在开发中：

• GPU 直通支持：通过 WSLg 机制扩展到容器场景
• Kubernetes 集成：与 k3s 的深度集成，提供 wslc k3s 命令
• 插件 API：允许第三方扩展 wslc 的功能
• Docker Desktop 迁移工具：一键将 Docker Desktop 的镜像、容器、卷迁移到 WSLC
• ARM64 原生支持：针对 Windows on ARM 设备的优化

11.2 社区生态展望

WSLC 的开源性质（底层 runwsl 项目托管在 GitHub）与微软在开源社区的活跃参与，为生态发展奠定了基础：

• Portainer 等管理工具的适配：Portainer 社区已在讨论 WSLC 支持计划
• CI/CD 平台的官方支持：GitHub Actions、GitLab CI 的 Windows Runner 镜像将预装 wslc
• IDE 集成：VS Code Remote - Containers 插件有望增加 WSLC 支持
• 安全扫描工具：Trivy、Snyk 等容器安全工具的 WSLC 兼容版本

11.3 对 Docker Desktop 的影响

WSLC 的出现并不意味着 Docker Desktop 会消亡。Docker Desktop 拥有数十年的社区积累、成熟的插件生态和企业支持体系。但对于 Windows 平台的轻量级容器化场景，WSLC 正在成为更具吸引力的选择。

这类似于当年 macOS 上 Homebrew vs MacPorts 的格局——两者共存，Homebrew 成为大多数场景下的默认选择。

总结

WSL Container（WSLC）是微软近年来在 Windows 开发者体验上最重要的技术投入之一。它将 Linux 容器能力从"需要安装额外软件的虚拟机体验"提升为"Windows 系统原生能力"，彻底改变了 Windows 开发者的容器化工作流。

核心价值回顾：

1. 极低的资源开销：12MB 空载内存 vs Docker Desktop 的 380MB，在资源受限环境中优势明显
2. 系统级集成：容器作为 Windows 内核的一等公民，不依赖第三方守护进程
3. 与 Docker 生态的零成本迁移：Dockerfile 兼容、CLI 接口相近、Compose V2 支持
4. 性能优势：I/O 吞吐快 40-60%、容器冷启动快 44%
5. 免费且无商业限制：不收订阅费，无企业许可证要求

当前局限：

• GPU 直通、Kubernetes 支持、插件生态等功能尚在开发中
• 公测期可能存在稳定性问题
• 不适合需要本地 GPU 加速的机器学习工作流

推荐策略：对于绝大多数 Windows 平台的容器化开发需求，现在就可以将 WSLC 作为 Docker Desktop 的替代方案进行评估和试点。采用本文所述的"渐进式迁移策略"，在保留 Docker Desktop 作为备选的同时，逐步将工作负载迁移到 WSLC，观察稳定性和兼容性。对于需要 Kubernetes 或 GPU 支持的专业场景，可以继续使用 Docker Desktop，或组合使用两者。

Windows 开发者等了多年的"原生 Linux 容器"体验，现在终于到来了。