配图说明：本文封面为 AI 生成图像。
9 月 29 日，微软官方宣布 WSL 容器（WSL Containers）正式发布。从 7 月初的公测到转正只用了三个月，现在只要运行一条 wsl --update，Windows 11 用户就能在不安装 Docker Desktop 的前提下，直接构建、运行和部署 Linux 容器。
wslc：把 docker 命令几乎原样搬了过来
正式版带来两个东西：WSL 容器 CLI（wslc.exe，别名 container.exe）和 WSL 容器 API。前者让开发者直接在 Windows 上操作 Linux 容器，后者则允许原生 Windows 应用以编程方式运行容器，官方举的场景是运行本地 AI 工作负载或容器化的云端应用。
迁移成本几乎为零。微软直接把大部分 docker 命令原样替换成了 wslc：运行容器是 wslc run，构建镜像是 wslc build，拉取镜像默认走 Docker Hub。唯一固执的地方是查看容器列表用 list 而不是 docker 用户的肌肉记忆 ps。从命令对照表看，run、build、pull、exec、logs、network 这些高频操作全部覆盖，常规开发场景基本可以无缝切换。
当然，转正版仍有缺口：Compose 暂未支持，GPU 支持情况也还需验证。不过微软已经明确，下一个目标就是 wslc compose，目标是让现有的 compose.yaml 文件无需修改直接可用。
动的是 Docker Desktop 的蛋糕
这件事真正的影响在于生态位。过去 Windows 上跑容器几乎只有两条路：装 Docker Desktop（大公司要注意商业授权费用），或者忍受 WSL 里手动折腾。Docker Desktop 的常驻虚拟机还以吃内存著称，8GB 内存的笔记本开着它基本没法干别的。WSL 容器把容器的运行时下沉到 WSL 本体，操作系统层面直接提供能力，Docker Desktop 的中间层价值被显著削弱。
对 Docker 公司来说，这当然不是好消息，但也不算突然。容器运行时的原生化是平台厂商的一贯打法：苹果在 macOS 上做了 container 框架，微软现在补齐了 Windows 的拼图。Docker 的护城河正在从运行时转移到开发者工具链和云服务上。
Windows 开发环境的分水岭
从 7 月公测到 9 月底转正，三个月的节奏在微软的开发者工具演进里算得上快。公测期间社区反馈集中在 compose 缺失和 GPU 直通两个痛点上，前者已经有明确的路线图，后者则随着 WSL 本体持续更新在逐步完善。对团队开发者来说，迁移评估可以现在开始：CI 流水线里如果只用基础容器操作，切换成本接近于零；如果有复杂的 compose 编排和 Docker Desktop 专属功能，不妨把迁移计划排到 compose 支持落地之后。
更值得展开的是 API 这一层。以往容器对 Windows 应用来说是外部工具，要靠命令行或 Docker SDK 间接调用；现在任何 Windows 应用都能内嵌容器能力。结合 Windows 上的 AI 开发热潮，本地跑一个向量数据库容器、一键起一个模型推理服务，这类场景的门槛被大幅拉低。
对普通开发者，建议现在就执行 wsl –update 体验一下，日常开发流如果重度依赖 compose，可以再等一个版本周期。但方向已经很清楚：容器能力正在成为 Windows 的系统级标配，就像当年的 WSL 一样，只是这一次，微软瞄准的是整条云原生工具链。
参考：小众软件《Windows 11 原生 Linux 容器正式发布，不再需要 Docker Desktop》报道，本文为基于公开信息的独立评述。