Windows 11 现在可以通过 WSL 容器运行 Linux 容器，无需 Docker Desktop（上手体验）
WSL 容器在 Windows 11 上运行 现在，Windows 11 可以独立构建、运行和管理 Linux 容器，无需在后台依赖 Docker Desktop。微软将其称为 WSL Containers。我们安装了预览版并实际跑了一些工作负载，下面就来看看哪些功能可用、哪些地方仍然需要 Docker，以及如何在你自己的电脑上启用它。
WSL Container 不应与下一代 WSL 2 混淆，因为我们已经介绍过微软如何终结 WSL 3 的传闻。它现在已作为公开预览版发布，所以我们安装了它，从零开始构建了一个自定义容器镜像，并通过几个工作流测试它的表现。
Windows 11 中的 WSL Container 是什么
WSL Container 是 Windows Subsystem for Linux 的内置功能，可让你直接从 Windows 创建、运行和管理 Linux 容器，无需安装 Docker Desktop、Podman Desktop 或任何其他第三方运行时。它分为两部分：
- 第一部分是 wslc.exe，这是一个命令行工具，在你更新 WSL 后会立即加入 PATH。微软还提供了一个名为 container.exe 的别名，因此这两个命令指向同一个二进制文件。用过 Docker 的人会觉得这个语法很熟悉，因为像 wslc run、wslc build 和 wslc container list 这样的命令，几乎与 Docker 的结构一一对应。
- 第二部分是 WSL Container API，以 NuGet 包形式分发，支持 C、C++ 和 C#。Windows 应用开发者可以用它将 Linux 容器直接嵌入自己的应用中。
Windows 应用无需让用户安装独立运行时，而是可以在后台悄悄启动一个 Linux 容器来运行某段仅适用于 Linux 的代码，任务完成后再将其销毁。微软用 Moonray 做了演示：这是一款开源 Linux 渲染引擎，曾用于《荒野机器人》等影片，它在 Windows 可执行文件中运行时，完全看不出 Linux 参与其中。
Moonray 是一款基于 Linux 的渲染引擎，可通过 WSL Container 在 Windows 内运行 
在 WSL Container 中运行 Moonray 
Moonray 渲染输出 使用该 API 的每个 Windows 应用都会获得自己独立的、由 Hyper-V 支持的虚拟机，与其他应用的容器彼此隔离。CLI 流程也会有自己的虚拟机。相比之下，Docker Desktop 会让所有容器运行在一个共享虚拟机中，正如你所预期的那样，这样更高效。
WSL Containers 以一定的资源效率为代价，换来了应用之间的强隔离边界，这也解释了微软为何将其定位为适合企业环境。
话虽如此，这两个入口最终都连接到同一个 WSL 服务，而该服务本来就负责管理你的常规发行版；在 Linux 虚拟机内部，真正执行容器工作的运行时是 Moby，也就是同样驱动 Docker 的开源引擎。需要注意的是，WSL Containers 并不是在重新发明容器，而是为 Windows 提供了一个第一方入口。
如何在 Windows 11 上安装 WSL Container
WSL Container 目前只在 WSL 的预发布通道中提供，因此在你的电脑上看到 wslc 之前，需要先切换到该通道。
在我们的测试机器上，使用较好的网络连接时，更新不到两分钟就完成了。如果更新后 wslc 仍无法识别，先重启终端；如果还不行，再重启电脑。由于它处于预发布通道，可能会有一些粗糙之处，微软自己 devblog 上的几位开发者就报告在运行第一个容器时遇到了 Catastrophic failure, Error code: E_UNEXPECTED。幸运的是，我们没有遇到这个问题。
如果你在想是否需要一台 Copilot+ PC 才能尝试这个功能，答案是不需要，因为 WSL Container 只是一个普通的 WSL 组件；但基于 Hyper-V 的隔离模式需要现代虚拟化支持，因此启用了 BIOS 或 UEFI 虚拟化的较新 CPU，在这里比普通 WSL 发行版更重要。
使用 wslc 构建并运行容器
在 wslc 正常工作后，我们没有去跑大家都在演示的基础 hello-world 示例，而是直接上了更接近真实场景的测试：从 Containerfile 构建一个自定义镜像，并从中暴露一个可用服务。
为 WSL 容器测试创建项目文件夹先做一个快速检查。我们交互式拉取并运行了一个 Debian 容器：
wslc run -it debian:latest
在容器内运行 uname -a 后，返回的是与 WSL2 相关联的 Linux 内核字符串，这证实我们确实位于真正的 Linux 环境中，而不是某种转换层之上。
在 WSL 容器内运行 uname -a 可确认它是真正的 Linux 内核，而不是转换层使用 Ctrl+P、Ctrl+Q 脱离后，再运行 wslc ps -a，会按自动生成的名称（mossy_sawtooth）列出该容器，并显示它启动于多久之前以及当前状态。
wslc ps -a 会列出所有容器，无论其正在运行还是已停止使用 wslc attach mossy_sawtooth 重新附加后，我们直接回到了同一个 shell。
重新附加到名为 mossy_sawtooth 的容器接着，我们编写了一个 Containerfile，它的工作方式与 Dockerfile 相同，用于打包一个小型 Linux 检查工具，可对放入其中的文件运行 file、exiftool 和 binutils。
Containerfile 的作用与 Dockerfile 相同，用于打包一个小型 Linux 检查工具这个文件大致如下：
FROM python:3.12-slim
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 build 构建自定义镜像构建会缓存基础层，因此再次构建只需几秒，而不是几分钟。运行 wslc image ls 后，可以确认该镜像已本地存在，并带有新的时间戳。
wslc image ls 确认自定义镜像已成功构建随后，我们通过端口映射启动容器，让 Linux 中运行的 Flask 服务器可以从 Windows 访问：
wslc run -d -p 5000:5000 –name inspector my-linux-inspector
在 Windows 端浏览器中打开 127.0.0.1:5000，就无需额外网络设置直接看到了该工具的网页界面。
Windows 可通过 localhost 访问 Linux 容器内的 Flask 服务器，无需额外网络设置在 Linux 内核上运行的服务，可以通过 Windows 上的 localhost 访问，而且无需安装任何第三方软件，这一句话就足以概括 WSL Container。
测试 WSL 容器中的 GPU 访问
GPU 直通是做 AI 或机器学习开发的人最关心的功能之一，因为它决定了 Linux 容器能否访问显卡，而不是只能依赖 CPU。WSL Container 通过 --gpus all 标志支持这一点，语法和 Docker 用户已经熟悉的一样：
wslc run --rm --gpus all pytorch/pytorch:2.5.1-cuda12.4-cudnn9-runtime \ python -c "import torch; print(torch.cuda.is_available())"下面的视频展示了它的实际效果：容器直接访问 GPU，然后将编译后的 PyTorch 模型与同一模型的普通 eager 模式运行速度进行对比。两者之间的差距非常明显。
https://www.windowslatest.com/wp-content/uploads/2026/07/testing-GPU-access-inside-a-WSL-container.mp4面向企业环境的 WSL Container
微软从预览阶段就把 WSL Container 定位为适合企业使用的方案。
Microsoft Defender for Endpoint 现有的 WSL 插件现在已能识别容器事件，因此监控 WSL 发行版的安全团队也能获得同样的容器可见性，而无需部署单独的工具，不过该功能目前仅限于一个需要单独报名的私有预览。
IT 管理员现在已经可以通过组策略和 ADMX 策略来控制 WSL Container，其中最重要的两项能力适用于受管设备群：
- 第一，管理员可以决定组织内的用户是否允许使用 WSL 发行版、容器，或两者都用。
- 第二，也是微软表示在客户需求中最常被提到的一点，管理员可以设置允许使用的容器镜像仓库白名单，从而让公司将拉取来源限制在内部或已批准的仓库，而不是让 Docker Hub 完全开放。
我们预计，在预览版发布后的几周内，这些设置就会在 Intune 控制台中获得完整支持。
从 0.462.0-pre-release 版本开始，VS Code 的 Dev Containers 扩展也已加入对 wslc 的支持。切换方法很简单：打开 Dev Container 设置，找到 Docker Path 字段，把它改成 wslc 即可，无需重装扩展或重新配置项目。
WSL Container 目前还缺什么
WSL Container 目前还没有类似 Docker Compose 的功能，因此使用 compose.yaml 文件同时启动数据库、后端和缓存的多服务项目，目前并不适合。我们测试的每个容器都必须单独启动。
当然，最大的缺失还包括没有 GUI 仪表板，也没有像 Docker Scout 那样的镜像扫描功能。此外，Docker Desktop 多年来建立起来的大量插件生态在这里也不存在。WSL Container 并不是要取代 Docker Desktop、Podman Desktop 或 Rancher Desktop，而这三种工具也都将受益于同样的底层平台改进，包括微软所说能让容器内 Windows 文件访问速度提升一倍的新 virtiofs 文件系统。
网络也经过了重新设计，加入了名为 Consomme 的实验模式，它会通过 Windows 网络栈转发 Linux 流量，而不是使用旧的 NAT 设置，目的是修复多年困扰 WSL 用户的 VPN 和代理兼容性问题。virtiofs 和 Consomme 目前都仅限于 WSL Container，但微软表示未来希望将它们引入普通 WSL 发行版。
你现在应该从 Docker Desktop 切换吗
对于本地开发中运行单个数据库容器或小型服务，WSL Container 已经能胜任，而且不需要单独授权。对于需要 Compose 文件、多服务联动或 Docker 扩展生态的场景，目前 Docker Desktop 仍然是更完整的工具。
微软计划在 2026 年秋季让 WSL Container 正式可用。考虑到它的 CLI 语法已经非常接近 Docker，缺失的大部分功能看起来更像是“何时实现”的问题，而不是“是否会实现”的问题。
如果你已经在 Windows 上运行 Linux 容器工作负载，那么把预发布版和 Docker Desktop 一起运行不会有任何成本，而且在它成为默认选择之前，还能让 WSL Container 先行一步。
支持原创新闻报道。
Windows Latest 依赖像你这样的读者。请把我们设为你在 Google Discover 和 Google 搜索 中的首选来源，帮助我们的独立报道触达更多人。
在 Discover 上关注我们 在 Google 上关注我们 提问（论坛）