本文依据微软官方 GA 博文与 Microsoft Learn 文档整理（2026-09-29 发布），命令均出自官方示例；笔者未在本地实测，涉及与 Docker Desktop 共存等行为已标注为待验证。

一句话： 微软把容器运行时直接塞进了 WSL。更新完 WSL，用 wslc 就能在 Windows 上构建、运行 Linux 容器，命令和 Docker 基本一个样，还附带一套给 Windows 应用调用的 API——Docker Desktop 在很多场景下可以先放一边了。

痛点：在 Windows 上跑个容器，先得请尊大神回来

以前在 Windows 上正经跑 Linux 容器，路径基本只有一条：装 Docker Desktop。问题是它对个人用户并不轻：

• 安装包大、后台常驻服务，开机就占着内存；
• 公司电脑上用还有商用授权的顾虑，个人折腾也总觉得杀鸡用牛刀；
• 家里自托管一堆小服务的人，实际多数只是跑几个单容器，Docker Desktop 的编排和界面根本用不上。

另一条路是自己在 WSL 发行版里装 Docker Engine，能折腾，但每次开机手动拉服务、网络和文件路径的坑都得自己填。

微软这次的思路很简单：既然 WSL 已经是 Windows 上跑 Linux 的地基，容器运行时就不要再外挂了，直接内置。

它能解决什么

1. 一行更新，自带容器运行时

终端里跑一句 wsl --update 就能拿到。入口有两个：

• CLI：wslc.exe，另带一个别名 container.exe，命令风格就是冲着 Docker 用户的肌肉记忆去的；
• API：WSL containers API，原生 Windows 应用可以以编程方式拉取、运行 Linux 容器，官方点名的主打场景是本地 AI 负载——比如 Windows 桌面应用想在本地跑一个模型服务容器，不用再让用户先装 Docker Desktop。这对做本地 AI 工具的人是个实打实的利好（本站之前写的 Agent Reach 就是给 AI Agent 补能力的，这类工具链以后多了一个系统级容器底座）。

2. GA 新增的一批日常命令

正式版补齐了很多预览期缺的生命周期管理能力：

• wslc container restart 重启容器、wslc container cp 用 tar 包在容器和宿主机之间拷文件；
• wslc system info 一眼看清容器环境状态；wslc events 实时输出容器事件流；
• wslc network connect/disconnect 动态把容器挂到/摘出网络，network create 支持任意驱动选项；
• 容器健康检查；create/run 支持 --stop-timeout（可以设 -1 无限等）和 --mount 挂载；
• 默认会话的容器存储路径可以改到指定盘——镜像囤多了不至于挤爆 C 盘。

3. 平台层面的红利

• 访问 Windows 文件的性能最高约 2 倍提升，跨系统拷文件这个老瓶颈缓解了；
• 新增 consomme 网络模式，改善容器网络兼容性；
• 生态跟得很快：VS Code 的 dev containers 可以直接用 wslc 当驱动，Aspire 把 WSL Containers 当一等运行时，社区还有 Lazywslc（终端 TUI 面板）和 WSL Container Desktop（WinUI 3 桌面端）补 GUI 的缺。

先看门槛

硬性要求只有一个（出自 Microsoft Learn 的 WSL container 文档）：

• WSL 版本 2.9.3 或更高。跑 wsl --update 更新，用 wsl --version 自查版本；
• WSL 本身的系统要求照旧：Windows 11，或 Windows 10 21H2 以上版本，BIOS 里开启硬件虚拟化；
• VS Code、Windows Terminal 都是可选，不装也能用命令行玩转。

没有显卡之类的额外硬件门槛。想跑 GPU 容器的话，官方 API 已明确支持 GPU 访问；CLI 侧具体的 GPU 参数用法，建议以官方文档为准（待验证），本文不凭 Docker 的习惯硬套。

上手四步（按官方教程，未实测）

以下命令出自 Microsoft Learn 官方入门教程，我在自己的机器上还没跑过，先照着文档给想尝鲜的人铺路：

1. 更新 WSL 并确认版本

wsl --update
wsl --version

2. 跑通第一个容器

wslc run --rm -it ubuntu:latest bash -c "echo Hello world from WSL container!"

3. 起一个 nginx，验证端口映射

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

4. 查看与收尾

wslc container ps
wslc image ls
wslc container stop web

用过 Docker 的人看这组命令应该毫无障碍。两边常用操作的对照：

操作	Docker	WSL 容器
运行容器	docker run	wslc run
构建镜像	docker build	wslc build
查看容器	docker ps	wslc container ps
镜像列表	docker images	wslc image ls
停止容器	docker stop	wslc container stop
重启容器	docker restart	wslc container restart
拷贝文件	docker cp	wslc container cp
系统信息	docker info	wslc system info
多容器编排	docker compose up	暂未支持

常见问题

Compose 什么时候来？

微软在 GA 博文里明确说：wslc compose 是呼声最高的功能，也是下一阶段的第一优先级，目标是现有的 compose.yaml 不改一个字就能 wsl compose up。但没给时间表，GA 时点还用不了。

镜像从哪拉？

官方示例里 wslc run nginx 直接就能跑，走的是 Docker Hub 这一套默认镜像拉取逻辑，你现有的镜像使用习惯不用改。

和 Docker Desktop 能共存吗？

未经实测，待验证。 两边都建立在 WSL2 的虚拟化底座上，理论上是两套独立运行时，但端口占用、镜像存储是否互通、会不会互相影响，得真装上双跑一段时间才知道。主力机上别一上来就卸 Docker Desktop，先并行试。

局限与不适合人群

• Compose 项目迁不过来：这是当前最大的缺口。像本站之前自托管的 腾讯开源 WeKnora，靠 Docker Compose 一键部署，服务拆成好几个容器协同——这类项目现阶段只能继续留在 Docker 那边。
• 没有官方 GUI：管理全靠命令行，看不惯终端的可以试试社区的 WSL Container Desktop 或 Lazywslc，但稳定性和官方出品不是一回事。
• 毕竟是 GA 第一版：健康检查、事件流这些都是正式版才补上的，边角坑要等社区踩一阵子。企业侧有 Intune 开关和镜像白名单、Defender 覆盖，个人用户一句带过即可。

是否值得试

分人群给结论：

• 单容器、GPU 推理、临时测试环境为主：现在就可以换。省掉 Docker Desktop 的常驻和体积，命令习惯又不用改，迁移成本几乎为零。
• 手里一堆 Compose 编排的自托管玩家：先别动，等 wslc compose 落地再考虑整体迁移，这段时间双轨并行最稳妥。
• 给 Windows 应用做本地 AI 功能的开发者：容器 API 值得认真看一眼，这是 Docker Desktop 给不了的系统级集成方式。

总的判断：WSL 容器不是来革 Docker 命的，它是把「Windows 上跑个 Linux 容器」这件事的门槛拉到了系统自带的水平。你的工作流越轻，它替代 Docker Desktop 的程度就越高。