WSL 3.0发布:不装Docker,文件访问快2倍

9 月 29 日，微软把 WSL containers 转成正式版，随 WSL 3.0.1 一起发。

一条 wsl --update，Windows 11 上就多出一套原生容器运行时，不用再先装一个 Docker Desktop。

消息传回国内是 9 月 30 日，隔天就挂上了知乎热榜。吵得最凶的不是技术细节，是身份问题：微软这是要顺手把 Docker 干掉吗？

先给结论：被替换的不是 Docker，是"先装一个第三方运行时"这个前置步骤。真正的变化藏在进程归属和治理开关里，而这两处恰恰是普通开发者一划而过、企业 IT 部门会逐条看的地方。

不用装 Docker 了，但微软要的不是这个

把 GA 的清单摊开，实际能用的东西是这个量级：一个命令行工具 wslc.exe，一套容器生命周期命令，一个给 Windows 原生程序调用的 API，一组企业管控开关。

安装路径很轻。终端里跑 wsl --update，或者从 GitHub 拿最新 release。预览期间必须先加的那个 --pre-release 参数，现在已经不需要了。

命令行这边，微软还塞了一个内置别名 container.exe。你不用改肌肉记忆，原来敲 docker ps 那种节奏，换个名字就能对上。

这一点很容易被读成"微软在模仿 Docker CLI，准备正面对打"。但官方博客里反复强调的关键词不是"替代"，是"不用再引入第三方工具带来的安装成本和许可成本"。

差别的分量在这里：一个需要采购、需要单独打补丁、需要安全团队另建监控的第三方软件，和一个随 Windows 更新走、能被现有管理平台统管的系统组件，在企业里根本不是同一类东西。

一句话说清：wslc 到底给了你什么

如果只用一句话描述它：WSL 从一个"能在 Windows 里跑 Linux 发行版"的兼容层，变成了一个"能在 Windows 里跑 Linux 容器"的运行时。

注意主语的落点。以前你在 Windows 上跑容器，链条是 Windows 到 WSL，到发行版，再装 Docker 或 Podman，最后才是容器。现在这条链中间的软件被抽掉了，WSL 自己就是容器引擎。

拆开看，能力分三层给。

命令行层，wslc.exe 负责构建、运行、部署，配一个直接叫 container.exe 的别名。生命周期上的细节在 GA 里补齐了不少：容器重启、通过 tar 归档进出文件、实时事件流、健康检查，还有容器网络和卷的挂载参数。

程序调用层，是面向 Windows 原生应用的 API，以 NuGet 包形式发布，支持 C、C++ 和 C#。官方点名的场景包括让 Windows 程序直接驱动 Linux 容器里的本地 AI 负载，以及把云端已经容器化的应用拉到本地跑。

工具链层，容器工具包和 VS Code 的 Dev Containers、Aspire 都接了进来，社区还自己写了几个管理界面，有命令行的，也有桌面窗口的。

拆开看：容器凭什么长在 Windows 上

这一节值得慢读，因为"不用装第三方"听起来只是省了一步，实际改的是架构。

先看进程归属。原来的 WSL 里，一个叫 wslservice.exe 的特权 Windows 服务创建虚拟机之后，自己一直持有它。新架构把这一步拆开了：wslservice.exe 造完虚拟机就交给一个子进程 wslcsession.exe，由它代表你的用户身份去做所有会话操作，建容器、挂目录、绑端口都归它。

拆出来的收益有两条。会话之间因为活在不同进程里，隔离更硬；会话操作跑在权限更低的进程里，即使这一段被攻破，也够不到特权服务那一层。这是把"能跑容器"变成"敢在企业里放开容器"的必经一步。

再看存储。每个 wslc 会话有一个自己的虚拟磁盘，镜像、容器、网络、卷这些状态全在里面，默认落在用户目录下的 wslcsessions 路径，GA 之后还能自己指定放到哪个盘。

容器要访问 Windows 上的路径时，走的是 virtiofs。整个挂载过程是：Windows 侧目录经 virtiofs 共享进 Linux 虚拟机，在虚拟机里落到 /mnt 下，再以绑定挂载的方式接进容器。还有一类卷由虚拟磁盘直接支撑，适合需要原生 Linux 文件系统、或者想给卷强加容量上限的场合。

最后看网络。新的网络模式叫 Consommé，思路是把 Linux 虚拟机的流量全部当成以太网帧丢进 virtio 队列，由一个以用户身份运行的 Windows 进程读走，由它来应答 DNS、路由 TCP 和 UDP、处理端口映射。

关键在出口：这些流量从 Windows 出去的时候，看起来就是一个普通 Windows 进程发的。VPN 和防火墙不需要为它开特例。之前容器网络在隔离环境里连不通、绕不开代理和策略的问题，就是从这条路径上解开的。

这里还藏着一个容易被跳过、但对日常影响不小的细节。会话彼此独立这件事，是双向的。

好处是开一个干净环境几乎不要成本。镜像、容器、网络、卷都归会话自己，出了问题删掉这个会话重来，不会污染主环境，也不用担心上一轮实验留下的残留。

代价是会话之间默认不共享镜像。你开三个会话各自拉一份同一个基础镜像，磁盘上就是三份。同时跑多个独立环境的人，得留意存储会随会话数量线性增长，GA 里那个把会话存储指到指定盘符的选项，就是为这种场景准备的。

放到场景里：这 2 倍快在哪条路上

标题里那个"快 2 倍"，官方口径写得很明确：从 Linux 环境访问 Windows 文件时，性能最高可到 2 倍​。对比对象是旧的文件共享方案 plan9，替换者是 virtiofs。

这句话得拆开读，否则容易高估。

提速发生在跨操作系统的访问上，而不是 Linux 内部的读写。你在 Linux 侧编译、跑测试、读写自己的目录，走的是会话虚拟磁盘那条路，跟 virtiofs 没关系，这次基本没有变化。

受益最大的，是原来最慢的那条路。Windows 上开 IDE、代码仓库放在 Windows 盘符里、构建和测试却在 Linux 侧跑，这种两边来回切的工作方式，瓶颈从来就是跨系统的文件访问。你在 /mnt/c 下面跑一次依赖安装，或者对一个大型仓库做状态扫描，等的那几十秒，主要就花在这里。

还有一个容易被忽略的事实：virtiofs 不是 3.0 才有的。六月底的公开预览里它就已经登场。这次 GA 做的是把它变成默认启用，并且明确说这项底层改进会同时惠及 WSL 发行版本身和构建在 WSL 上的其它容器技术。

对纯容器工作流的开发者来说，2 倍 这个数字的直接体感可能有限。真正被它救到的，是那些离不开 Windows 图形界面、又舍不得把仓库搬进 Linux 文件系统的人。

常见误区纠偏

误区一：WSL 3.0 是微软要干掉 Docker。

这个说法有一定道理，因为命名太像了。container.exe 这个别名，加上卷、网络、健康检查这一整套命令分层，明显是在贴着大家已有的肌肉记忆设计；VS Code 的 Dev Containers 甚至允许把 wslc 指定为默认驱动。看起来就是一次正面对标。

但它解释不了一件事：多服务编排没在这次 GA 里。官方把 compose 支持列为"最受期待的功能"，目标写得很清楚，是让 wsl compose up 能直接吃现有的 compose.yaml 文件、不用改。也就是说，Docker 生态里最被日常依赖的那一层，微软不但没动，还准备兼容它。镜像仓库生态、集群编排、跨主机那一整套，更不在射程之内。

更准确的理解是：被替换的是"安装一个第三方运行时"这一步，以及它附带的许可成本和运维负担。你原来在 WSL 里跑的 Docker，没有任何理由现在就停掉。

误区二：文件访问快一倍，等于所有文件操作都快了。

数字是官方给的，口径没错，所以这话看着站得住。

但它解释不了为什么有人装完感觉没变化。因为这个数字限定在"Windows 路径挂进 Linux"这一段，而且是比较 virtiofs 和 plan9 两种挂载文件系统得出的。全程在 Linux 侧工作的人，这条路径根本不经过。

更准确的理解是：这是一次针对已知瓶颈的定点优化，专治"代码在 Windows、构建在 Linux"的割裂感。如果你的工作流本来就把仓库整个放在 Linux 文件系统里，别指望装完有感知。

误区三：现有的容器工作流可以原样平移。

卷挂载、网络创建与连接、健康检查、事件流、停止超时，GA 补的这些都是日常真正用得上的东西，说"看起来齐了"不算错。

可它解释不了多服务项目怎么迁移。编排这一层还没有，官方也只是说"已经开始做了，有进展会分享"。现在把多服务项目压上来，会卡在编排上。

更准确的理解是：单容器、脚本化任务、在容器里跑一次测试环境，这类场景现在就可以评估；本地多服务的开发环境，要么等 compose，要么继续用现有方案。

企业 IT 为什么要为一条容器命令加两个开关

这次发布里，有一块内容被大多数技术解读略过了，但它可能才是决定这条命令能不能进公司电脑的关键。

微软在 Intune 里为 WSL 容器加了两个设置项。一个控制整个容器功能的开关，可以直接关掉；另一个是镜像来源的允许清单，管理员定义好受信任的仓库之后，开发者只能从清单内拉镜像。

Microsoft Defender for Endpoint 原来那个面向 WSL 的插件，这次把容器也纳了进来。容器里的进程、文件、网络活动能被采集出来，并且和 Windows 主机侧的行为关联起来。

翻译成一句人话：安全团队不需要为容器再建一套独立的监控流程，用现有的那套就能查。

这就是为什么这次的容器运行时，和过去那些"自己下载来爽一爽"的方案不是一个物种。对企业来说，能不能用从来不是技术问题，是治理问题。有没有统一的开关、有没有可审计的来源限制、出事之后能不能接到已有的告警链条上，这三件事决定了它会不会被允许出现在办公设备上。

另外，微软这次把 WSL 的命令行工具、后台服务、容器启动组件和 WSLg 图形堆栈都按 MIT 许可证开了源。这一步不太好直接换算成收益，但它降低了"这套东西会不会哪天被锁起来"的顾虑。

谁今天该动手，谁可以再等等

判断标准其实不复杂，看你的痛点落在哪一层。

建议现在就升的：在 Windows 上做开发、又不想为容器再叠一层虚拟化的人；代码在 Windows 盘符、构建在 Linux 侧、长期被跨系统文件访问拖住的人；所在团队需要镜像来源合规、需要管理平台能覆盖的；想在本地跑容器化 AI 负载、让 Windows 程序直接调度 Linux 容器的。

可以先观察的：重度依赖 compose 做多服务本地编排的，GA 里还没有；本地已有一套稳定容器工具链、且对"开发机和生产环境运行时一致"有硬要求的团队，多引入一套运行时反而增加差异，除非打算统一。

如果你打算试，三步就够，全程不动现有环境。第一步，跑 wsl --update 把版本提上来，再用 wslc system info 看一眼环境状态，不满意可以卸掉回退到旧版。第二步，找一个单容器场景先跑通，别拿多服务项目开局，这一步的目的是验证镜像能不能拉到、端口映射通不通。第三步，再验证你最在意的那个性能点，也就是把仓库放在 Windows 盘符、构建放在 Linux 侧，跑一次完整构建做前后对比。

这套路径的适用边界也很清楚：它验证的是"值不值得纳入日常工作流"，不是"能不能替换现有生产编排"。生产环境那套东西，这次发布没有触及。

最后留个判断信号。这次发布真正的信息量不在"少装一个软件"，在于微软把 Linux 容器从"开发者自己找来装的东西"，改造成了 Windows 自己的一个可被企业统一治理的组件。工具归谁管，往往比工具跑多快更能决定它的命运。

你现在的开发机，容器到底是工作必需，还是当初顺手装上的那一层？

如果觉得今天这篇有启发，点个在看，顺手转发给需要的朋友；想第一时间收到推送，可以星标我⭐。

关注我，每天陪你聪明看世界 —— 看懂热搜，玩懂AI。

作者提示含AI生成内容。作者声明本文无利益相关，欢迎值友理性交流，和谐讨论～