在 Windows 上跑 Linux 容器这件事，我折腾了差不多六七年，中间换过三种姿势：一是在系统里装一套带图形界面的容器桌面客户端，守护进程、后台服务、文件同步一股脑塞进来，开机自启项能排半屏；二是自己开一个 WSL 发行版，手动装运行时、配 cgroup、跟权限和 iptables 搏斗；三是干脆买台小主机当远程构建机，本地只留客户端。三种都能用，但没有一种让我觉得"顺手"。WSL Containers（下面统一简称 wslc）出来后，我第一次感觉到这条链路被压短了——容器不再是叠在 WSL 之上的一层外挂，而是成了 WSL 自身的子命令，镜像、容器、网络都归同一套生命周期管。这篇复盘记录我从零装到日常用的完整过程，包括那些文档里不会写、只有真跑一遍才会撞上的坑。适合两类人看：一是在 Windows 上做开发、想少装一套重型工具的人；二是已经会用容器、想搞清楚 wslc 到底值不值得迁移过来的人。基础概念我会顺手解释，但不会从"什么是镜像"讲起。

1. wslc 到底是什么：定位拆解与方案取舍

1.1 三层结构：Windows、WSL 虚拟机、容器

理解 wslc 的关键，是先理清它下面垫着什么。WSL2 本身不是"Windows 上的一个 Linux 兼容层"，而是一个由系统虚拟化能力托起来的轻量虚拟机，里面跑着一个真实的内核。过去的用法是：这个虚拟机里装一个发行版用户空间，你在里面敲命令。而 wslc 做的事情，是在同一个虚拟机内核之上，再叠一层容器运行时，让容器直接以这个内核为宿主。换句话说，容器不是跑在某个发行版里，而是跑在 WSL 的虚拟机里，和发行版平级。

这个结构带来一个很实际的结果：容器启动不需要再拉起一台虚拟机，也不需要先启动一个重量级守护进程再去连它。你敲下运行命令，镜像层解压、命名空间创建、进程拉起，整个过程在几百毫秒量级完成。我实测冷启动一个精简镜像，从命令回车到容器内提示符出现，大概在 0.4 到 0.8 秒之间波动，热启动更快。这个数字放在桌面客户端的场景里是不敢想的，后者光是后台服务初始化就得几秒。

代价也很明确：wslc 的容器共享 WSL 虚拟机这一个内核，你没法像在完整虚拟化方案里那样，给不同容器指定不同内核版本。如果你的业务需要验证特定内核模块、特定内核参数行为，那这套结构天生不适合，还是得回到"一台虚拟机一个内核"的老路。这一点在选型阶段就要想清楚，别等做了一半才发现内核版本对不上。

再补充一个容易忽略的点：因为容器和发行版共享同一个虚拟机，它们之间的资源是"共享池"关系。容器吃掉的 CPU、内存，和你在发行版里跑的编译进程，是同一个池子里抢。这既是优点（不用重复预留资源），也是隐患（一个跑飞的容器能把你的交互终端一起拖慢）。后面第 6 节我会讲怎么给这个池子设上限。

1.2 和桌面版容器客户端、裸装引擎的横向对比

光说结构太虚，直接上对比。我把三种常见方案按我这几年最在意的几个维度列了张表，评分是我自己用下来的主观感受，不是跑分。

从表里能看出来，wslc 的定位非常窄，也非常清晰：它服务的是"我在本机写代码，需要快速起个依赖跑一下"这类场景。你要是需要图形化面板管理几十个容器、需要团队统一镜像构建环境、需要复杂的多机编排，那它不合适，别硬上。

我自己的取舍是这样的：日常开发用 wslc，因为启动快、不占后台；需要完整编排验证或者跑需要特权的构建任务时，切回裸装引擎那一套。两套并存不冲突，因为它们的镜像存储和网络命名空间是分开的，唯一要注意的是端口别撞车。这个"双轨"策略我用了几个月，切换成本很低，反而比死磕一套方案更省心。

提示：如果你的团队要求"开发环境和 CI 环境完全一致"，wslc 目前的基础编排能力可能撑不住，先做小范围验证再推广，别一上来就全量替换。

2. 装之前先把地基打好：环境盘点与前置条件

2.1 系统版本、虚拟化与 WSL 版本的三道门槛

装 wslc 失败的人，九成卡在门槛上，而不是卡在命令上。我把这三道门槛按检查顺序列出来，你可以照着一条条过。

第一道是系统版本。WSL2 的容器能力依赖较新的系统组件，太老的系统版本即使能开 WSL，也拿不到容器子命令。检查方式很简单，在命令行里敲winver，弹出的窗口会告诉你版本号。我建议直接升到当前主流的稳定大版本，别在旧版本上打补丁，因为容器功能牵扯到虚拟化层和文件系统驱动，补丁覆盖不全。

第二道是虚拟化开关。WSL2 本质是虚拟机，必须要有硬件虚拟化支持。打开任务管理器，切到"性能"页，看 CPU 那一栏底部有没有"虚拟化：已启用"。如果是"已禁用"，就得进固件设置里开。这一步没开，后面所有命令都会以各种奇怪的方式失败，最常见的是虚拟机启动超时。

第三道是 WSL 本体版本。在命令行敲：

wsl --version

输出的版本号要足够新，容器子命令才会出现。如果版本偏旧，先更新：

wsl --update

更新完再敲一次wsl --version确认。这里有个小坑：wsl --update默认走稳定通道，如果你要的功能还在预览通道，得额外加参数走预览更新。具体参数名各版本有差异，建议直接敲wsl --update --help看当前版本支持什么，别照抄网上的老命令。我就因为照抄了一条两年前的更新命令，反复失败半小时，最后发现参数早就改了。

三道门槛都过了，再往下走。顺序别乱，我见过有人先装了一堆东西，最后发现虚拟化没开，全部推倒重来。

2.2 资源预算：内存、磁盘和内核参数的取舍

门槛过了，接下来是给这套东西分多少资源。这里最容易犯的错是"全给默认值"，然后发现编译大项目时整机卡死，或者磁盘被镜像撑爆。

先说内存。WSL 虚拟机的内存默认会跟着物理内存走，上限相当宽松。问题是容器和发行版共享这个池子，一旦某个容器内存泄漏，整个虚拟机都会被拖慢，连带你的编辑器、终端全部卡住。我的做法是显式设上限，公式大概是：物理内存的 50% 到 60%，但不超过 16 GB。比如 32 GB 的机器，给 WSL 分配 16 GB；16 GB 的机器，给 8 GB。这个比例是根据"容器只跑依赖服务、重活交给宿主机"的假设定的。如果你要在里面跑大型编译，可以往上调，但别超过 70%，得给宿主机留出余量，否则系统本身会开始频繁换页。

再说磁盘。镜像层是实打实占空间的，一个基础镜像加几个依赖，几百 MB 很常见；构建缓存更是无底洞。我的经验是预留至少 60 GB 给 WSL 的虚拟磁盘，并且开启虚拟磁盘自动收缩，否则删了镜像空间也不会还回来。这个开关在配置文件里，下一节给具体写法。

最后是处理器核数。默认会吃满物理核，听起来很美，实际会让宿主机调度变得迟钝。我一般设成物理核数减二，比如 8 核机器给 6 核。留给宿主机两个核处理界面刷新和输入响应，体感差别很明显。

这张表不是教条，是起点。你可以先按它配，跑一周看实际占用再微调。我自己的机器上，这套配置撑住了日常开发加偶尔的镜像构建，内存峰值没超过上限的八成。

3. 安装与初始化：从零到第一个容器跑起来

3.1 组件开关与更新链路

环境盘完，开始装。这一步的核心不是"敲哪条命令"，而是理解更新链路：容器能力是随 WSL 本体分发的，所以你不需要单独下载安装包，只要保证 WSL 是最新的、并且相关组件开关是开的。

组件开关这块，用系统自带的功能管理命令最稳妥。以管理员身份打开命令行，依次执行：

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

两条命令分别对应子系统本身和虚拟机平台。执行完必须重启，别偷懒跳过。重启后再敲一次wsl --update，让本体走到最新。

这里有个真实踩过的坑：有些机器上装了多个 WSL 发行版，更新的时候只更新了其中一个。容器能力是虚拟机级别的，和发行版无关，但版本信息可能显示得不一致，让你误以为没更新成功。判断方法是看wsl --version输出的本体版本，而不是wsl -l -v里每个发行版的版本。这两个数字含义不同，我一开始就搞混了，白折腾一轮。

更新完成后，验证容器子命令是否存在：

wslc --help

能打出帮助信息，说明装好了。如果提示找不到命令，回到 2.1 节重新过一遍三道门槛，大概率是版本不够新。

3.2 配置文件怎么写

配置文件是这套东西真正好用的关键，很多人装完就用默认值，然后抱怨"内存吃太多""磁盘越来越大"。配置文件放在用户目录下，文件名是.wslconfig，用文本编辑器直接改。下面是我目前在用的版本，注释写清了每一项的意图：

[wsl2] # 内存上限，按物理内存的 55% 估算 memory=16GB # 处理器核数，物理核数减二 processors=6 # 交换空间，内存上限的四分之一 swap=4GB # 开启内存自动回收，闲置一段时间后把缓存还给系统 autoMemoryReclaim=gradual # 虚拟磁盘自动收缩，删除内容后空间能还回来 sparseVhd=true # 关闭页面报告，减少后台开销 pageReporting=false [experimental] # 允许容器使用宿主机的部分能力，按需开启 autoProxy=true

改完必须完全关闭 WSL 再启动才生效：

wsl --shutdown

这条命令会关掉所有发行版和容器，执行前确认没在跑重要任务。我一般会在关闭前先看一眼容器列表，避免误杀正在跑的数据库。

关于自动内存回收，这个特性值得单独说。它的作用是：当虚拟机内一段时间没有内存压力时，把空闲页还给 Windows。不开的话，你会看到任务管理器里那个虚拟机进程的内存占用只涨不落，哪怕里面啥都没跑。开了之后，闲置几分钟占用就会明显下降。我用下来的体感是，从"占用 8 GB 不还"变成"闲置后回落到 2-3 GB"，对笔记本用户特别友好。

注意：自动收缩和内存回收都是"温和"机制，不会立刻见效。如果你刚删完一堆镜像就盯着磁盘看，会发现空间没马上回来，等几分钟或者手动触发一次清理再观察。

3.3 验证与首次运行

配置生效后，跑第一个容器验证整条链路。我用的是最小化的验证方式，先拉一个精简镜像：

wslc pull alpine:3.20

拉完看本地镜像列表：

wslc images

输出里应该能看到刚拉的镜像，包括仓库名、标签、镜像 ID 和大小。镜像 ID 是一串十六进制字符，后面清理和删除时要用到。

然后跑一个一次性容器：

wslc run --rm alpine:3.20 echo "container is alive"

--rm表示容器退出后自动删除，适合这种一次性验证。如果终端打印出那行文字，说明镜像拉取、容器创建、进程执行、退出清理这条链路全通了。

再进一步，进交互式终端看看：

wslc run --rm -it alpine:3.20 /bin/sh

进去之后敲几条命令，看看网络通不通、文件系统是不是独立的：

cat /etc/os-release ip addr ls / exit

这里要观察三件事：一是发行版标识对不对，确认镜像没拉错；二是网络接口有没有分到地址，确认容器网络正常；三是根目录结构是不是镜像自带的，确认没有和宿主机文件系统混在一起。

我第一次跑的时候，ip addr报命令不存在，因为精简镜像里没装网络工具。这不是故障，是镜像本身的裁剪。换成cat /proc/net/fib_trie或者装个工具包就能看。这类"看起来像故障其实不是"的情况，新手很容易慌，先确认镜像里到底有没有那个命令，再判断是不是环境问题。

4. 核心工作流：镜像、容器、数据、网络

4.1 镜像管理与拉取策略

镜像管理这块，wslc 的命令设计和主流容器工具基本一致，会用后者的话几乎没有学习成本。但有几个细节值得单独拎出来讲。

拉取镜像时，默认会去公共仓库找。如果你在内网环境，或者有私有仓库，需要先登录：

wslc login registry.example.internal

登录信息会存在本地，后续拉取私有镜像就不用重复输入。这里要提醒一句：登录凭据的存储位置和权限要留意，多人共用的机器上最好用完就登出：

wslc logout registry.example.internal

镜像列表的查看有几种粒度。只看顶层镜像用wslc images；要看全部包括中间层，加个参数：

wslc images -a

清理这块是重点。镜像和构建缓存不清，磁盘会以肉眼可见的速度膨胀。我的习惯是每周清一次悬空镜像：

wslc image prune

加-a会连未被任何容器引用的镜像一起清掉，慎用，因为它可能删掉你手动构建但暂时没跑的自定义镜像。我一般先不加-a跑一次，看看要删什么，确认没问题再加参数。

还有一个容易被忽略的点：镜像标签的管理。很多人习惯一直用latest，结果某天上游更新了，本地一拉，行为全变了，排查半天。我的做法是生产验证过的镜像固定版本号，比如alpine:3.20而不是alpine:latest；只有临时试验才用latest。这个习惯能省下大量"昨天还好好的今天怎么挂了"的排查时间。

4.2 容器生命周期操作

容器的生命周期无非创建、运行、查看、进入、停止、删除这几个动作，但每个动作都有值得说的细节。

后台运行是最常用的姿势：

wslc run -d --name web-demo -p 8080:80 nginx:1.27-alpine

-d是后台运行，--name给容器起个固定名字方便后续操作，-p做端口映射，把容器内的 80 端口映射到宿主机的 8080。起完之后浏览器访问本机 8080 应该能看到默认页面。这里有个高频坑：容器里的服务如果只监听127.0.0.1，端口映射是通不了的，必须监听0.0.0.0。这个后面第 5 节详细说。

查看运行中的容器：

wslc ps

加-a能看到已停止的。输出里的 STATUS 列会告诉你容器跑了多久、是否健康。如果配置了健康检查，这里会显示 healthy 或 unhealthy，比单纯看"在跑"有用得多。

进入正在运行的容器：

wslc exec -it web-demo /bin/sh

exec是在已运行的容器里新开一个进程，退出不会影响容器本身。这点和run要分清：run是新建容器，exec是进已有容器。我见过有人反复run同一个镜像想进去改配置，结果起了十几个容器，自己都数不清。

停止和删除：

wslc stop web-demo wslc rm web-demo

停止的容器还占着磁盘，要rm才真正释放。批量清理可以用：

wslc container prune

这条会删掉所有已停止的容器。执行前确认没有需要保留现场用于排查的容器，删了就找不回来了。

看日志也是高频操作：

wslc logs -f web-demo

-f是持续跟踪，类似tail -f。排查服务启动问题时，这个命令比进容器翻日志文件快得多。加--tail 100可以只看最后 100 行，避免一屏刷过去找不到关键信息。

4.3 数据卷与端口映射的实操细节

数据持久化是容器使用里最容易出问题的一环。容器删了数据就没了，这是设计如此，不是 bug。要保住数据，就得用挂载。

绑定挂载最直观，把宿主机的一个目录映射进容器：

wslc run -d --name>wslc volume create app-data wslc run -d --name vol-demo -v app-data:/var/lib/data alpine:3.20 sleep infinity

命名卷由运行时统一管理，位置固定，备份和迁移都方便。查看有哪些卷：

wslc volume ls

端口映射的坑比数据卷更多。基本语法是-p 宿主机端口:容器端口，还可以指定监听地址：

wslc run -d -p 127.0.0.1:8080:80 nginx:1.27-alpine

这样只有本机能访问，局域网内其他机器访问不到。开发环境我推荐这么写，安全边界清晰。如果确实需要局域网访问，改成0.0.0.0:8080:80，但要清楚这意味着同一网络下的其他设备都能连进来。

一个实际经验：端口冲突的报错信息往往很隐晦，只说"绑定失败"，不说被谁占了。排查时用系统命令看端口占用：

netstat -ano | findstr :8080

在 Windows 侧执行，能看到占用进程的 PID，再去任务管理器对号入座。这套流程我走过无数次，比盲猜快得多。

4.4 用容器文件构建自定义镜像

现成镜像不够用时就得自己构建。wslc 支持标准的容器构建文件，语法和主流工具一致，所以已有的构建文件基本能直接拿来用。

一个最小可用的例子：

FROM alpine:3.20 RUN apk add --no-cache curl WORKDIR /app COPY entry.sh /app/entry.sh RUN chmod +x /app/entry.sh CMD ["/app/entry.sh"]

构建命令：

wslc build -t my-tool:1.0 .

-t指定镜像名和标签，最后的点表示构建上下文是当前目录。构建过程中每一层都会缓存，改动的层之后的层会重新构建，之前的层直接复用。所以构建文件里把不常变的部分放前面，常变的部分放后面，能显著加快迭代速度。

构建缓存的管理要上心。缓存存在本地，用得越久占得越多。看缓存占用：

wslc system df

这条命令会列出镜像、容器、构建缓存各自占了多少空间。我一般看到缓存超过 5 GB 就清一次：

wslc builder prune

构建时还有一个实用参数是--no-cache，强制不用缓存重新构建。什么时候用？当你怀疑缓存导致构建结果不对时。我就遇到过一次：改了构建文件里的一行，但因为写法问题没触发缓存失效，构建出来的镜像还是旧行为，排查了快一小时才发现是缓存的问题。从那以后，改动涉及依赖安装顺序时，我会主动加--no-cache跑一次确认。

多阶段构建也支持，适合需要编译步骤的语言：

FROM alpine:3.20 AS builder RUN apk add --no-cache build-base WORKDIR /src COPY . . RUN make FROM alpine:3.20 COPY --from=builder /src/app /usr/local/bin/app CMD ["/usr/local/bin/app"]

这样最终镜像里不会带编译工具链，体积能小一大截。我做过对比，同样一个程序，单阶段构建出来 400 多 MB，多阶段能压到 20 MB 以内。对本地开发来说体积不是最要紧的，但镜像小了拉取和启动都快，长期看是划算的。

5. 踩坑实录：常见故障与排查路径

5.1 启动与命令层故障速查

这类故障的特点是：命令敲下去，要么报错，要么没反应，要么行为诡异。我把遇到过的整理成表，按现象查原因。

表格只能覆盖常见情况，真正排查还得靠日志。容器起不来时，第一件事是看日志而不是反复重试：

wslc logs <容器名>

如果容器根本没起来，日志是空的，那就换思路：先用交互模式跑，看它到底卡在哪一步：

wslc run --rm -it <镜像名> /bin/sh

能进去说明镜像本身没问题，问题出在启动命令；进不去说明镜像或运行时有问题。这个二分法能快速缩小范围，比盯着报错猜有效得多。

还有一个隐蔽的故障：容器显示在运行，但服务不通。这时候ps看到的状态是正常的，容易误判。我的处理顺序是：先exec进去看进程在不在，再curl本地端口看服务有没有监听，最后从宿主机侧测端口映射。三步走完，问题基本定位。

5.2 网络与端口不通的三条线索

端口映射配了但访问不到，这是最高频的问题，没有之一。我总结成三条线索，按顺序查。

第一条线索：服务监听地址。进容器执行：

wslc exec -it <容器名> /bin/sh netstat -tlnp

看服务监听的是0.0.0.0还是127.0.0.1。如果是后者，只有容器内部能访问，端口映射形同虚设。解决办法是改服务配置，让它监听所有地址。这是配置问题，不是环境问题，改完重启容器即可。

第二条线索：端口映射参数。确认-p的写法没把宿主机端口和容器端口搞反。格式是宿主机:容器，前面是外面看到的，后面是里面监听的。我见过写成-p 80:8080的，本意是访问 8080 却写反了，怎么都通不了。

第三条线索：宿主机侧的防火墙和端口占用。先在 Windows 侧确认端口有没有被别的程序占：

netstat -ano | findstr :8080

有输出说明被占了，换个端口或者停掉占用的程序。没输出再考虑防火墙策略。开发环境我一般不建议为了调试去动防火墙规则，换个端口更快。

还有一种情况是容器间通信不通。这时候要确认它们是不是在同一个自定义网络里。默认网络下容器之间只能通过 IP 访问，不能用名字。建个自定义网络再跑：

wslc network create demo-net wslc run -d --name svc-a --network demo-net alpine:3.20 sleep infinity wslc run -d --name svc-b --network demo-net alpine:3.20 sleep infinity

这样svc-b里就能直接用svc-a这个名字访问对方。这个机制靠的是内嵌的域名解析，比记 IP 靠谱得多，IP 重启就变，名字不变。

5.3 文件系统与权限的坑

文件系统这块的坑，我踩得最深。核心认知是：WSL 内部有两套文件系统，一套是虚拟机里的原生文件系统，一套是挂载进来的 Windows 盘。两者的性能差了一个数量级。

具体差多少？我做过一次粗糙的测试，同样解压一个几千文件的项目，放在原生文件系统里十几秒完成，放在 Windows 盘挂载点下要一分多钟，慢五六倍很常见。原因是跨文件系统的每次读写都要经过一层转换，小文件多的时候开销被放大得特别明显。

所以第一条经验：项目代码放原生文件系统，别放 Windows 盘。路径大概是/home/用户名/...，别用/mnt/c/...。这一条能解决大部分"容器里跑得慢"的抱怨。

第二条经验：挂载权限。绑定挂载的目录，容器里的用户能不能读写，取决于宿主目录的权限位。经常出现的情况是，容器里跑的是非 root 用户，挂载进去的目录属主对不上，写不进去。解决办法有几种：一是构建镜像时把用户 ID 和宿主用户对齐；二是挂载时加权限参数；三是开发环境里干脆用 root 跑，但生产环境别这么干。

排查权限问题的命令很朴素，进去看就行：

wslc exec -it <容器名> /bin/sh id ls -ln /挂载点

id看当前用户和组，ls -ln看目录的数字属主。两边一对，问题就清楚了。数字对不上就是权限问题，对得上还写不了，那就是只读挂载或者文件系统本身的问题。

第三条经验：文件变更通知。某些开发工具依赖文件系统事件来触发重新加载，跨文件系统挂载时这类事件可能传不过来，表现为"改了代码页面不刷新"。遇到这种情况，要么把代码挪到原生文件系统，要么改用轮询模式。轮询模式费 CPU，但胜在稳定，取舍看你的机器性能。

6. 调优与落地：让它真正进入日常工作流

6.1 内存回收与磁盘瘦身

跑了一段时间之后，两件事会找上门：内存占用居高不下，磁盘空间莫名其妙少了几十 G。这两个问题都有解，但得理解机制。

内存这块，关键配置是自动回收。前面配置文件里开了autoMemoryReclaim=gradual，效果是虚拟机闲置一段时间后，把缓存页还给系统。我用下来的观察是：连续编译半小时，占用能到十几 G；停手十分钟左右，回落到三四 G。这个回落不是线性的，前几分钟降得快，后面慢慢磨。别指望它秒回，机制就是这样。

如果想更激进一点，可以设成更积极的档位。但我不太建议，因为回收太积极会导致频繁的冷启动，反而拖慢响应。均衡点在哪，取决于你的使用节奏：整天连着开发就温和点，一天只用一两次就激进点。

磁盘这块，光删东西不够，还得让虚拟磁盘收缩。开了sparseVhd=true之后，删除的内容会在后台慢慢释放。但有个前提：虚拟机内部的文件系统得先真正把块标记为空闲。所以顺序是：先清镜像和缓存，再等系统回收，最后才看到磁盘变小。

清理命令按力度从小到大排：

wslc container prune wslc image prune wslc builder prune wslc system prune

最后一条最狠，会清掉所有未使用的东西，包括网络和构建缓存。我一般一个月跑一次，跑之前确认没有要保留的镜像。如果磁盘实在收不回来，还有个终极手段：备份重要数据后重建整个 WSL 实例。这个操作代价大，慎用，但确实能一次性解决问题。

看空间分布用这条：

wslc system df -v

-v会列出每一项的明细，哪个镜像占了多少、哪个缓存占了多少，一目了然。比起盲目清理，先看清楚再动手效率高得多。

6.2 和编辑器、脚本、自动化任务的联动

工具好不好用，最终看它能不能融进日常流程。wslc 在这方面有个天然优势：它就在 WSL 里，而大部分编辑器的远程开发能力都是围绕 WSL 设计的，两者天然契合。

最常见的用法是：编辑器连到 WSL 里的项目目录，容器在同一个环境里跑依赖服务。这样代码在编辑器里改，服务在容器里热加载，端口映射到本机浏览器预览。整条链路的延迟很低，因为代码、容器、编辑器都在同一个虚拟机里，只有最后的浏览器访问跨了一层。

脚本化方面，我习惯把常用的启动命令写成脚本，避免每次手敲一长串参数：

#!/bin/sh set -e wslc network create dev-net 2>/dev/null || true wslc run -d --name dev-redis --network dev-net -p 6379:6379 redis:7-alpine wslc run -d --name dev-pg --network dev-net -p 5432:5432 \ -e POSTGRES_PASSWORD=devpass postgres:16-alpine echo "dependencies are up"

几行脚本解决每天开工前的重复劳动。set -e让脚本遇错即停，避免状态混乱；|| true那行是幂等处理，网络已存在时不报错。这类小细节看着不起眼，积累下来能省不少时间。

自动化任务的话，wslc 适合做"本地预检"这一环：提交前本地跑一遍镜像构建和基础测试，确认没明显问题再推。它不适合做长时间运行的 CI，因为本地机器会休眠、会关机，可靠性不如专门的构建机。这个边界要认清，别把本地工具当服务端用。

还有一个实用场景是环境隔离验证。比如你要确认某个依赖升级会不会出问题，可以在容器里跑新旧两个版本对比，宿主环境一点不受影响。这种"用完即弃"的验证方式，比我以前"装完再卸、卸不干净重装系统"的经历优雅太多了。

6.3 我在实际取舍中的几条经验

用到现在，有几条经验是我觉得比命令本身更重要的，写出来供参考。

第一条：别把它当成万能方案。wslc 的强项是"快"和"轻"，弱项是"全"和"稳"。需要复杂编排、需要多机协同、需要长期稳定运行的服务，都不该放在这里。我见过有人把本地开发环境搭得比生产还复杂，最后维护成本高到离谱，完全背离了工具的初衷。工具是拿来省事的，不是拿来炫技的。

第二条：版本要锁。镜像标签锁版本，配置文件也建议纳入版本管理。我就吃过亏：某次顺手改了配置没记录，过了两周发现内存行为不对，翻遍历史才想起来改过什么。现在我的.wslconfig和启动脚本都放在一个私有仓库里，改动留痕，出问题能快速回滚。

第三条：清理要形成习惯。容器工具的通病是"用着用着就满了"，wslc 也不例外。我给自己定的节奏是每周清一次悬空资源，每月做一次全面清理。听起来麻烦，实际每次也就一两分钟，比某天突然发现磁盘红了再手忙脚乱强得多。

第四条：出问题先看日志，别先搜。搜出来的答案大概率对不上你的版本和场景，而日志是当下的、真实的。我排查效率最高的时候，都是静下心来看日志、逐步二分定位的时候；效率最低的时候，都是疯狂搜索然后照着不相干的方案乱试的时候。

第五条：保留一条退路。不管工具多好用，我都会保留一套能独立工作的备用方案。不是因为不信任，而是因为开发环境出问题时，你需要的是快速恢复，而不是先花两小时修工具。这个习惯让我在很多次环境故障里保持了节奏，没被工具绑架。

最后分享一个我最近才用顺的小技巧：把常用的镜像和依赖服务提前拉好、起好，用固定的容器名管理，开机后一条脚本全部拉起来。这样每天的"环境准备"时间从十几分钟压缩到几十秒，注意力可以直接放在正事上。这个思路不新鲜，但配合 wslc 的启动速度，体验上的提升比预期明显得多。