WSL Containers 实战：2026 年 Windows 原生 Linux 容器开发指南

过去在 Windows 上跑 Linux 容器，基本绕不开 Docker Desktop：它提供了成熟的图形界面、Compose 编排和完整生态，但也带来了资源占用、商业授权和额外的虚拟化层。WSL Containers 的出现并不是要立刻取代所有 Docker 场景，而是给 Windows 开发者提供了一个更轻、更原生的容器入口。对于单服务开发、本地测试、容器化部署验证和学习容器基础命令，wslc 已经足够好用。

先澄清一个常见误解：没有"WSL 3"

微软 WSL 产品经理 Craig Loewen 在 Build 2026 后明确澄清：不存在所谓的 WSL 3。WSL Containers 不是 WSL 2 的版本继任者，而是基于现有 WSL 基础设施新增的容器功能层。它随 WSL 更新推送，Windows 11 用户升级 WSL 后即可使用。

2026 年 9 月 30 日发布的 WSL 3.0.1 已正式通用可用，并带来 wslc 工具、Linux 6.18 内核、virtiofs 和 consomme 网络模式等能力。但"WSL 3.0.1"更多是版本号标识，不代表 WSL 2 被取代。

安装与启用

1. 确认系统条件

Windows 11，建议保持系统更新到最新版本。
BIOS/UEFI 中已开启 CPU 虚拟化（Intel VT-x / AMD-V）。
已安装 WSL。未安装可执行：

wsl --install

2. 升级 WSL

执行：

复制代码

wsl --update

如果当前版本尚未包含容器功能，可尝试预发布通道：

复制代码

wsl --update --pre-release

随后重启 WSL：

复制代码

wsl --shutdown

3. 验证 wslc 是否可用

复制代码

wsl --version
wslc --version
wslc run --rm hello-world

如果看到容器输出，说明环境已就绪。

wslc 与 Docker 命令对照

wslc 的设计目标是让 Docker 用户几乎零学习成本迁移。常见命令对照如下：

Docker	wslc	说明
`docker run`	`wslc run`	启动容器
`docker ps`	`wslc container ps`	查看运行中容器
`docker images`	`wslc image ls`	查看本地镜像
`docker pull`	`wslc pull`	拉取镜像
`docker exec`	`wslc exec`	进入容器
`docker logs`	`wslc container logs`	查看日志
`docker stop`	`wslc stop`	停止容器
`docker rm`	`wslc rm`	删除容器

也可以直接使用 container 命令，它是 wslc 的内置别名。

常用实战示例

运行 Nginx

复制代码

wslc run -d -p 8080:80 --name web nginx

访问：

复制代码

curl http://localhost:8080

停止并清理：

复制代码

wslc stop web
wslc rm web

交互式 Ubuntu 容器

复制代码

wslc run --rm -it ubuntu:latest bash

挂载 Windows 目录

复制代码

wslc run --rm -it -v ${PWD}:/app alpine:latest sh

注意：跨系统文件访问适合快速调试，但高 IO 项目仍建议放在 WSL 内部文件系统。

构建项目镜像

如果项目根目录包含 Dockerfile，可以直接构建：

复制代码

wslc build -t myapp:latest .
wslc run -d -p 8080:8080 --name myapp myapp:latest

GPU 直通

如果已安装 NVIDIA 驱动并支持 CUDA，可执行：

复制代码

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

VS Code 集成

VS Code 的 Dev Containers 扩展已在 0.462.0 预发布版中添加对 wslc 的支持。安装扩展后，可以在 WSL 容器中打开项目、附加调试器，并获得接近本地开发的体验。

推荐流程：

在 WSL 中克隆项目。
使用 VS Code 远程连接 WSL。
通过 Dev Containers 打开容器工作区。
在容器内执行构建、测试和调试。

这种方式比在 Windows 侧直接操作容器更符合云原生开发习惯，也能避免跨文件系统带来的 IO 损耗。

性能调优：把容器放在正确的地方

1. 源码优先放在 WSL 内部

如果项目包含大量小文件，例如 Node、Python、Rust 项目，建议将代码放在 WSL 的 ext4 文件系统中，而不是 Windows 分区。跨边界访问会明显拖慢 npm install、pip install、cargo build 等操作。

2. 容器存储可重定向到 Dev Drive

如果希望镜像和容器数据持久化到 Windows 侧，并且获得更好的 IO 性能，可以将 WSL 内的容器存储绑定到 Dev Drive：

bash 复制代码

sudo mkdir -p /mnt/d/docker-data
sudo mount --bind /mnt/d/docker-data /var/lib/containers

注意：必须通过 WSL 内部挂载点访问，不要使用 \\wsl$\ UNC 路径。

3. 配置 .wslconfig

在 Windows 用户目录下创建或编辑 %USERPROFILE%\.wslconfig：

复制代码

[wsl2]
memory=12GB
processors=6
swap=4GB
networkingMode=mirrored
localhostForwarding=true
dnsTunneling=true
firewall=true
autoProxy=true

其中 consomme 网络模式会让 WSL 和容器的网络流量经过 Windows 主机转发，从而更容易复用 Windows 的代理、VPN 和企业网络策略。

企业网络与代理场景

旧版 WSL 在 NAT 模式下，容器经常无法直接使用 Windows 代理。consomme 网络模式正是为了解决这个问题：Linux 侧流量通过 Windows 主机转发，容器可以继承宿主机的代理设置。

对于企业内网开发者，这意味着：

拉取镜像时更容易走公司代理。
容器访问内网服务更稳定。
VPN 环境下的容器网络问题明显减少。

但如果公司通过组策略限制了 WSL 或容器功能，仍需先确认合规要求。

安全与治理

WSL Containers 提供了比传统第三方容器工具更贴近 Windows 管理框架的能力。企业可通过组策略和 ADMX 模板控制 WSL 发行版与容器使用，并设置镜像允许列表。Microsoft Defender for Endpoint 的 WSL 插件也已更新，可感知 Linux 容器内事件。

开发者侧建议：

不要将密钥、Token、.env 文件打包进镜像。
使用环境变量或 Secrets 管理敏感配置。
定期清理不再使用的镜像和容器。
对公网镜像保持警惕，优先使用官方或可信仓库。

当前限制与避坑

Compose 支持仍有限：复杂多服务编排不建议立刻迁移到 wslc。
没有官方图形界面：查看日志、监控状态主要依赖命令行。
仅支持 Linux 容器：不能直接运行 Windows 容器。
Docker Socket 不直接暴露：依赖 Docker Socket 的第三方工具可能无法直接使用。
镜像源配置不如 Docker 成熟：国内拉取镜像时可能需要指定镜像仓库地址。
预览到 GA 过渡期仍有变化：命令、参数和企业策略可能继续调整。

什么时候适合用 wslc

适合：

单服务本地开发。
快速验证镜像、端口、环境变量。
学习容器基础命令。
想减少 Docker Desktop 资源占用。
企业内网需要复用 Windows 代理和 VPN。

暂不建议：

重度依赖 Docker Compose 的多服务编排。
需要 Kubernetes 本地调试。
强依赖 Docker Socket 的第三方工具链。
生产环境尚未完成安全评估。

小结

WSL Containers 不是 Docker Desktop 的"完全替代品"，而是 Windows 原生容器能力的重要补位。它把容器运行时下沉到 WSL 层，让开发者可以用熟悉的 CLI 直接运行 Linux 容器，同时获得更低的资源占用、更好的跨系统文件性能和更友好的企业网络兼容性。

对于个人开发者，它可以作为轻量容器工作流的首选；对于团队，它可以作为标准化开发环境的一部分。后续如果继续扩展这个系列，可以分别写"wslc + Dev Drive 存储优化""wslc + VS Code 远程容器""wslc 企业组策略治理"和"从 Docker Desktop 迁移到 wslc 的实战清单"。