别再开虚拟机了！微软原生 WSLC 容器，才是 Windows 跑容器的终极答案！

前言

之前如果需要在 Windows 上跑 docker 容器的话，一般会选择 Docker Desktop，优点是操作方便、兼容性强，但是问题也很多，比如我的笔记本跑起来就很吃内存，启动也慢。微软刚刚发布了全新的原生方案——WSL Container（wslc），一条命令替代 Docker，零成本平替，免费开源，无守护进程，还有 GPU 直通，好用多了。

先理解 wslc 到底新在哪

"又一个跑容器的工具"这样的印象会让人低估它。它真正的变化在架构层面：

Docker Desktop 是四层叠加：

一个完整的 Linux 虚拟机（不是轻量 VM）
里面跑 dockerd 守护进程
Windows 侧的 GUI 面板 + 托盘程序
宿主与虚拟机之间的文件共享代理

四层加起来，空闲状态就要吃掉 1 GB 以上的内存，开机自启动还慢。

wslc 直接把这些"叠层"拍平了：微软把容器运行时（镜像管理 + OCI 运行时）直接做进了 WSL2 的内核/发行版层，由 WSL 那台轻量虚拟机承载，没有常驻的 dockerd。所以：

"零额外安装"是真的 —— wsl --update --pre-release 之后它就在那儿了
"无守护进程"也是真的 —— 容器进程就是 WSL 里的普通进程，虚拟机不启动就没有任何后台开销
闲置内存低，是因为它复用你已经开着的 WSL2，而不是再开一台虚拟机

为什么 wslc pull nginx 能直接拉 Docker Hub 的镜像？ 很多人以为是微软做了兼容转换，其实不是：容器镜像是 OCI 规范（Open Container Initiative）定义的产物，Docker 只是众多实现之一。只要镜像符合 OCI，containerd、Podman、wslc 都能拉、都能跑。所以"命令和 Docker 几乎一样"不是巧合 —— 它们操作的是同一套标准。

安装实操

前置条件

CPU 开启硬件虚拟化（BIOS 里开 Intel VT-x 或 AMD-V）
Windows 10 2004+ 或 Windows 11
已启用「适用于 Linux 的 Windows 子系统」和「虚拟机平台」
WSL 版本 ≥ 2.9.3（wslc 最低支持基线）

Step 1：更新 WSL 到预览版

稳定版 WSL 不含 wslc，必须拉取预发布版本。打开管理员权限的 PowerShell：

纯文本

wsl --update --pre-release

看到类似「正在更新适用于 Linux 的 Windows 子系统: 2.9.4」就说明成功了。

Step 2：关闭所有 WSL 实例

纯文本

wsl --shutdown

彻底释放正在运行的 WSL 内核进程，保证新版本内核完整加载。

Step 3：重新开一个新终端

这是最容易踩坑的一步！更新后旧终端无法识别 wslc 命令，因为旧终端进程启动时加载的 PATH 缓存里还没有 wslc.exe。必须关掉所有已打开的 PowerShell / Windows Terminal 窗口，重新新开一个管理员终端。

仅执行 wsl --shutdown 是不够的——它只关闭 Linux 内核，不会刷新 Windows 终端的可执行文件缓存。

Step 4：校验 WSL 版本

纯文本

wsl --version

确认输出中 WSL 版本 ≥ 2.9.3：

纯文本

WSL 版本: 2.9.4.0
内核版本: 6.18.35.2-1
WSLg 版本: 1.0.79

Step 5：校验 wslc

纯文本

wslc version

正常返回 wslc 2.9.4.0 就说明安装成功了！

核心命令速查（Docker 用户秒上手）

wslc 的语法几乎完全对齐 Docker，原有的肌肉记忆可以直接迁移：

镜像管理

纯文本

# 拉取 OCI 镜像（和 Docker Hub 兼容）
wslc pull ubuntu
wslc pull nginx

# 列出本地镜像
wslc image ls
# 等价写法
wslc images

# 删除镜像
wslc image rm ubuntu

# 清理无标签冗余镜像
wslc image prune

容器生命周期

纯文本

# 临时测试容器，退出自动销毁
wslc run --rm hello-world

# 交互式进入 Ubuntu
wslc run --rm -it ubuntu bash

# 后台启动 Nginx，端口映射 8080:80
wslc run -d --name web -p 8080:80 nginx

# 查看运行中的容器
wslc container ps
# 等价写法
wslc ps

# 查看全部容器（含已停止）
wslc ps -a

# 停止 / 启动 / 删除
wslc stop web
wslc start web
wslc rm web

# 一键清理所有已停止容器
wslc container prune

辅助运维

纯文本

# 实时查看容器资源占用
wslc stats

# 查看容器日志
wslc logs web

# 构建自定义镜像
wslc build -t myapp:latest .

# 查看帮助
wslc --help

实测体验：容器启动基本秒开，比 Docker Desktop 冷启动快不少。微软用了新的 virtiofs 文件系统，宿主机和容器之间的文件读写性能大约提升了 2 倍。以前挂载目录跑前端热重载的卡顿感明显改善。

virtiofs 是什么？为什么能快一倍？ WSL2 早期用的是 9p 协议做宿主↔Linux 的文件共享 —— 它是通用的网络文件协议，跑在这种"本地共享"场景里开销偏大，尤其是元数据操作（比如检测文件变动的热重载，需要不停 stat 大量小文件），延迟很明显。virtiofs 是专门为虚拟化设计的共享文件系统，走更高效的通道、元数据路径更短，所以"文件读写提升约 2 倍"主要来自这里。
⚠️ 但要注意：跨系统访问仍然是最慢的路径。哪怕有了 virtiofs，"在 Linux 里读 Windows 盘上的代码"依然比自己 Linux 文件系统内慢得多。所以跑构建、跑热重载时，把项目放在 Linux 侧目录（~/project）依然是第一选择。

杀手锏：GPU 直通

对于 AI/ML 开发者来说，这是最兴奋的功能。wslc 通过 CDI（Container Device Interface）直接暴露宿主机 GPU，不需要 Docker daemon 中转：

纯文本

# 测试 CUDA 是否可用
wslc run --rm --gpus all pytorch/pytorch:2.5.1-cuda12.4-cudnn9-runtime python -c "import torch; print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))"

输出你的显卡型号：

纯文本

True
NVIDIA GeForce MX450

一个命令拉起 CUDA 容器，跑 PyTorch 推理，GPU 直通开箱即用。不需要装 nvidia-container-toolkit，不需要配 Docker GPU 运行时。

CDI（Container Device Interface）是干什么的？ 它是 CNCF 的一个规范：用一份 JSON 文件描述"宿主机上有哪些设备、怎么把它们暴露给容器"。在它出现之前，各家方案要么写专有的 hook 脚本（NVIDIA 的 nvidia-container-toolkit 就是这种），要么在运行时里硬编码。CDI 把这些标准化了，于是任何支持 CDI 的运行时都能用同一种方式拿到 GPU。--gpus all 背后就是去读设备的 CDI 描述。
实用含义："不用装 nvidia-container-toolkit"不是省了一行命令，而是少了一个最容易在升级后失配的组件。

3 个不踩坑实操建议

建议 1：安装后必须重启终端

最高频踩坑点。执行 wsl --update --pre-release 后，旧终端进程的 PATH 缓存里还没有 wslc.exe。正确流程：更新 → shutdown → 关闭所有终端 → 重新新开管理员终端 → 验证版本。如果新开终端还不行，用 Test-Path C:\Windows\System32\wslc.exe 检查二进制文件是否存在，不存在就重新更新。终极兜底：重启电脑。

建议 2：多工具共存，不冲突

Windows 上可以同时保留传统 WSL 发行版（Ubuntu、Debian 等）、Podman machine、wslc 三套环境。三者内核运行层隔离，互不抢占资源。日常开发用 wslc 跑轻量容器，需要 Docker Compose 或 K8s 时切回 Docker Desktop 或 Podman，按需切换即可。

建议 3：了解当前限制，别盲目替换

WSLC 目前处于公开预览阶段，以下功能暂不支持： ❌ Docker Compose（多容器编排） ❌ 自定义复杂网桥网络 ❌ 持久卷高级挂载 ❌ 可视化管理面板（纯 CLI） ❌ K8s 集群

如果你的工作流强依赖 docker-compose.yml，现阶段不建议完全卸载 Docker Desktop。把 wslc 当作轻量替代 + 补充工具使用更稳妥。

"公开预览"这四个字的分量，比它看起来重。 它意味着：CLI 的参数与行为可能在任何一次更新中变化、不保证向后兼容、微软明确不建议用于生产环境。所以对它的合理定位是"轻量开发工具 + 学习尝鲜"，而不是"把生产工作流迁过来"。反正它和 Docker Desktop 可以共存，没必要二选一。

WSLC vs Docker Desktop vs Podman 对比

对比维度	WSLC	Docker Desktop	Podman (WSL)
安装方式	WSL 预发布更新，无独立程序	完整客户端安装包	单独下载安装
常驻后台进程	无守护程序，随容器启停	常驻 dockerd + 托盘 GUI	无根架构，无常驻守护
闲置内存占用	最低，复用现有 WSL 2	高，空闲 1 GB+	中等
命令语法	90% 兼容 Docker	原生 Docker 标准	100% 兼容 Docker
GPU/CUDA	原生 WSL 2 显卡直通	支持但需额外配置	原生支持
Compose / K8s	暂不支持	完整支持	支持 Compose（插件）
可视化界面	纯 CLI	完整 GUI 面板	可选第三方 GUI
企业费用	免费	$9~$24/人/月（商用）	免费

关于最后一行"费用"，补一个大多数文章没说的前提：Docker Desktop 对个人、教育、开源项目，以及"小型企业"（员工少于 250 人且年收入低于 1000 万美元）本来就是免费的。要付费的是超出这个门槛的商业使用。
所以"wslc 免费"这个优势，对家用和小团队其实意义不大（你本来就不用付钱）；它真正省的是大公司的授权成本。选型时别被"免费"两个字单独带跑，还是要看功能是否匹配。

完整实操示例

示例 1：快速搭建 Nginx 网页服务

纯文本

# 拉取官方 Nginx 镜像
wslc pull nginx

# 后台启动容器，端口映射 8080
wslc run -d --name demo-nginx -p 8080:80 nginx

# Windows 浏览器访问 http://localhost:8080

# 查看运行状态
wslc ps

# 停止并清理
wslc stop demo-nginx
wslc rm demo-nginx

示例 2：交互式 Ubuntu 开发环境

纯文本

# 拉取 22.04 稳定版
wslc pull ubuntu:22.04

# 进入交互式终端，退出后容器自动销毁
wslc run --rm -it ubuntu:22.04 bash

# 容器内可执行 apt、Python、CUDA 推理等操作

示例 3：跑一个 Linux 桌面环境

纯文本

wslc run -d --name=webtop -e PUID=1000 -e PGID=1000 -e TZ=Etc/UTC -p 3000:3000 -p 3001:3001 lscr.io/linuxserver/webtop:ubuntu-kde

浏览器打开 http://localhost:3000，一个完整的 Linux KDE 桌面就跑起来了！

总结

WSLC 是什么：微软把容器运行时直接做进了 WSL 2 内核，无需 Docker Desktop 即可在 Windows 上构建、运行、管理 Linux 容器。

核心优势：免费、零额外安装、命令兼容 Docker、GPU 直通、资源占用低、文件 IO 性能翻倍。

适合谁：本地轻量开发、临时数据库/中间件容器、AI 推理环境、不想装重型容器客户端的用户。

不适合谁：需要 Docker Compose、K8s、可视化面板、企业集群管理的生产环境。

最佳实践：wslc + Docker Desktop 双工具共存，轻量任务用 wslc，复杂编排用 Docker，按需切换。

如果你想要的其实是一台稳定、完整、能跑 Compose 的 Linux 环境（而不是"偶尔跑个容器"），那还是走成熟路线更省心：在 WSL 里装一个发行版，再按服务器的方式配好 Docker、面板和开机自启 —— 用 Windows 自带的 WSL 跑 Docker 容器。两条路线不冲突，完全可以共存。