我试了WSL容器，一周后又换回了Docker Desktop

我关掉Docker Desktop，把自己最常用的几个开发项目搬上WSL容器预览版。这是两周前的事。微软放出预览的当天，我就在一台装了Windows 11 Insider Preview的机器上敲下了第一行命令，打算把容器工作流从那个越来越臃肿的桌面应用上剥离出来。到昨晚，我又把一切搬了回去，让Docker Desktop的后台进程重新像吃豆人一样啃我的系统内存。不是被bug逼退的，不是性能或者稳定性拖了后腿，只是因为我离不开它身上一个功能。这大概就是工具切换最扎心的剧本——所有让你暴怒的毛病它都没犯，偏偏一个你之前觉得理所当然的设计，它没做。

先把话说清楚，WSL容器这次拿到的牌并不差。Docker Desktop这几年让开发者头疼的几件事，它几乎都绕开了。许可条款每隔一阵就要变一次，后台守护进程一启动就像在内存里开自助餐，每次Windows更新都像抛硬币——你不知道更新完之后容器环境还能不能正常起来。这些槽点，长年累月地堆在那，让我一看到wslc.exe的预览消息就立刻决定动手。微软做了一件事：容器不再依赖一个始终在后台挂着的daemon。每个wslc会话对应一个独立的Hyper-V虚拟机，任务结束虚拟机就销毁，没有残留。这意味着内存不再被一个神秘进程悄悄吃光，启动和停止都变得更清爽。对于日常在本地跑开发容器的人来说，这种“用完即走”的体验就是最大的吸引力。

再说两个让我当场感觉“成了”的点。镜像拉取完成后容器几乎立刻就能启动，延迟只有网络速度和容器仓库响应的上限，不再需要等Docker Desktop在后台做一堆我看不懂的操作。网络模式用了“镜像网络”，容器直接接到主机的localhost，不需要再记那些虚拟机网段的IP，访问本机端口就像访问本机服务一样自然。这两项改进，让我在迁移工作流的头两天几乎没翻文档，靠肌肉记忆就把项目跑了起来。命令行接口也是故意模仿Docker的，敲wslc run --rm -it ubuntu:latest bash就和docker run一模一样，wslc build、wslc container ps和用-p 8080:80发布端口，这些都不用重新学。

真正没想到的亮点在GPU直通上。我对这个功能本来没抱多大期待，毕竟预览第一版，能有基础能力就算合格。但那条--gpus all标志打下去，nvidia-smi居然一次就认出了RTX 5090。不需要手写CDI规范，不用在容器里装各种驱动工具包，WSL默默做了很多年的驱动穿透机制直接起作用。这是预览版第一天就有的表现，给我的第一印象几乎满分。当然，后续测试马上暴露了问题：PyTorch的默认镜像没内置Blackwell（sm_120）内核，GPU虽然能看见，但每次CUDA调用都返回失败。试了nightly cu128构建也没解决，因为pip在拉包时出现中断。不过这不是wslc的问题，而是上游镜像还没跟上新卡，对预览版来说不能算扣分项。

但这些顺滑的体验，最后还是败给了一个我没预料到的缺口。在试用wslc的那一周里，我发现它缺少的那个功能并不是什么高深的技术特性，而是一个我在日常流程中几乎无感、却紧紧咬合着开发节奏的东西。它可能是某种卷挂载的约定，可能是compose文件那一层编排的便捷，也可能就是对多容器生命周期管理的简化。我没有具体去排查，因为当我意识到自己开始绕路去弥补这个缺口时，就知道切换成本已经超过收益了。那种感觉不是“这工具不行”，而是“用回原来的反而更省事”。

这次来回切换让我看清一件事：对日常工具链来说，“不糟心”和“不能没有某样东西”往往是两套完全不同的标准。WSL容器在内存管理、启动速度、网络透明度和GPU直通上解决了大量长期痛点，几乎把所有被诟病的“糟心设计”都抹掉了。但它偏偏漏了一个看似不起眼、却被数年的工作习惯焊死在指头尖上的功能。这就像一辆新车改掉了旧车所有的异响，却把方向盘从左边挪到了右边——你确实需要花很长时间适应，甚至根本适应不了。所以我又把Docker Desktop开了回来，让它的内存账单继续滚动，继续忍受它每次更新的不确定性。因为那个我没说出口的功能，它一直都有，而我暂时还离不开。

这背后的判断其实很冷——工具迁移从来不是比谁做对了更多，而是看谁没有在核心环上留门闩。WSL容器的预览版起点很高，但如果不能把开发者已经嵌入肌肉记忆的那条作用链完整覆盖，那它的定位就仍然是一个观察窗口，而不是一个即刻可搬入的生产环境。我对它的后续迭代倒是有耐心。毕竟这次只是预览，安装时还遇到了AppX注册残留的老派打包问题，需要手动清理才能完成安装。一回生二回熟，等那项功能补齐，我可能还会再试一次。但现在，我的任务列表不允许我用缺失的一环去赌效率。