如果您可以在Windows应用程序中直接使用Linux代码而无需修改，会怎样？现在这已经成为现实。

　　在Windows上运行容器一直不如想象中那么简单。虽然有与WSL和Hyper-V兼容的Docker Desktop和Podman版本，但我发现它们都过于复杂且不稳定。当它们能够正常工作时，Hyper-V方案反而是最好的选择——通过Linux虚拟机来托管容器。然而，所有这些都带来了虚拟基础设施的开销，层层叠加影响开发效率，而且每次重启PC后都需要重建环境。

　　部分问题出在WSL本身。这是一个很好的工具，但WSL2的文件系统集成速度很慢，您必须借助Visual Studio Code的远程集成功能来处理代码，这意味着要在每个正在构建和测试的容器内部署VS Code服务器。如果使用Kubernetes，情况会更加复杂，需要额外管理，分散开发者的注意力。

　　我最终选择在一台独立的Linux服务器（运行containerd）上完成大部分容器测试和开发。尽管这种方式运行良好，且能充分利用工作站级硬件的资源，但它不便携，而且由于某种我尚未查明的原因，Ubuntu的远程桌面访问对我始终不可用。

　　因此，很高兴看到微软在Build 2026大会上发布了关于WSL的多项公告，将其作为推动Windows重新成为开发者平台的一部分。首先是改进中的WSL3（虽然还有一段时间），其次是将于6月底正式推出的WSL原生容器支持。同时，社区驱动的Docker Desktop类工具也已开始出现，用于帮助监控和管理容器。

　　推出基于WSL的容器平台，与Build大会上其他以开发者为中心的Windows公告相辅相成。鉴于Azure上超过50%的服务器运行Linux发行版，让Windows的行为更接近Linux，正是微软对开发者需求的回应。Linux是云原生基础设施的基石，因此开发者需要能够在任何地方构建它。

　　开始使用WSL容器

　　WSL容器提供了一个全新的CLI，它与现有的WSL命令并行工作，支持从创建到关闭的完整容器生命周期。您只需将WSL安装升级到当前预发布版本（截至本文撰写时为2.9.3）。打开管理员PowerShell终端，输入 wsl --update --pre-release 即可。

　　这条命令会下载并安装最新的WSL版本。关闭并重新打开终端（以确保上下文更新）后，输入 wslc 即可检查WSLC是否已安装，该命令会列出所有可用指令。如果您希望将容器工作与WSL分开（避免误操作影响WSL环境），新的CLI已别名为 wslc。

　　在底层，微软正借助WSL容器在Windows中探索Linux的新集成方式。其中一个关键变化是采用了新文件系统，大幅提升了容器内访问Windows文件的速度；另一项改进为WSL容器提供了新的网络模式，网络连接直接通过Windows网络堆栈中转，确保容器能够访问与Windows相同的资源和安全策略。

　　从Windows应用程序调用Linux容器

　　当您开始在Windows代码中使用WSL容器API时，事情会变得更加有趣。您可以在桌面应用程序中嵌入对Linux容器的调用，利用现有服务，在CI/CD流水线中构建和部署容器。新的文件系统和网络堆栈有助于降低跨越两个平台之间的摩擦。

　　WSL容器API以NuGet包的形式提供，支持C、C#和C++。它允许您的代码启动、停止容器，并直接与之交互——发送命令行指令并读取响应。更有趣的是，您可以从代码中启动容器化服务，并将其REST或gRPC API暴露在本地网络端口上。微软已经提供了示例代码，展示了早期阶段的各种可能。

　　微软正在做的事情具有革命性：它把云原生、服务驱动的模式引入Windows，并以此弥合数十年来Windows和Linux开发之间的鸿沟。您不再需要重写那些运行在Linux上的服务才能让它们在Windows中工作；只需将服务容器化，然后通过WSL容器API启动即可。任务完成后，API会自动清理，关闭容器并释放其占用的内存。

　　需要牢记的是，这只是一个快速演进平台的首次公开预览。例如，未来完全可以在为WSL1开发的syscall翻译层基础上，构建一个原生的Windows–Linux应用程序集成栈，从而省去基于Web的服务调用开销。未来走向值得期待，但这个初始版本已经相当亮眼。

　　从Windows管理Linux容器

　　如果您希望获得类似Docker Desktop的体验，在Windows开发机上构建和测试容器，那么您不用等太久。WSL容器的底层API已被用于构建管理和监控容器的工具。其中一个是WSL Container Desktop，目前正在GitHub上开发。虽然尚未发布正式版本，但您可以通过克隆源码仓库并自行编译来运行它。您需要安装Windows App SDK，部分功能还需要Azure CLI访问权限。

　　WSL Container Desktop采用C#编写，前端为WinUI。目前仅验证过在x64架构上可用，但我也在Arm64 PC上成功编译并运行了它，用来测试和运行容器。启动后，它会为WSL托管的容器提供一个精心设计的前端界面，展示运行中的容器及其资源占用情况。您还可以将WSL Container Desktop链接到Docker Hub或Azure Container Registry等容器注册表，方便快速拉取基础镜像，然后利用WSL容器环境添加自己的代码和定制内容。

　　主要交互界面是WSL Container Desktop的仪表板，它显示当前运行的容器及其资源使用情况。元素以卡片形式呈现，借鉴了Windows自身UI（尤其是设置应用）的风格。在仪表板中，您可以深入查看可用容器，提供快速启动、停止和重新加载等操作，以及扩展功能（例如打开浏览器访问对应端口）。我用一个包含完整KDE Plasma桌面的容器进行了测试，结果在浏览器中得到了一个运行Linux发行版的环境。

　　其他功能包括显示当前日志的详细信息视图，以及用于检查容器状态的工具——这对于调试和测试非常有用，因为它能提供WSL容器CLI无法给出的深入信息。此外，还有一个清理工具，可以帮助您在下载镜像后删除不再需要的内容，并通过分析显示体积最大的镜像和长期未使用的镜像。除核心功能外，WSL Container Desktop还提供了基本设置工具，方便您调整其外观以及与Windows的集成方式。

　　在Windows内运行Kubernetes，用于云原生开发

　　WSL Container Desktop更有用的功能之一是能够在WSL中快速搭建K3s Kubernetes实例。该实例可用于托管WSL容器，提供一个本地环境，让您随时随地构建和测试云原生应用。K3s工具提供了与Kubernetes项目自身的Headlamp UI相似的体验，使得在开发环境和生产集群之间切换变得轻而易举。

　　可以公平地说，WSL容器是那种您原本觉得“不需要”的功能，但一旦拥有，就再也离不开它。WSL容器简化了在Windows中构建容器开发工具链的流程，同时也启发您思考新一代混合应用——充分利用Windows和Linux几十年来的发展成果。

　　这样的场景在几年前还难以想象：将一个Linux容器嵌入Windows应用程序的中间，并把它当作另一个本地服务来对待。随着WSL容器平台的不断演进，我们有望看到更多融合Linux和Windows的方式，利用容器提供一个混合平台，最终让我们同时拥有两者的优势。