WSL2与Docker Desktop迁移非系统盘及C盘空间回收

1. 先想清楚：Docker 和 WSL2 到底把什么塞进了 C 盘

第一次在新机器上装完 Windows 11 + WSL2 + Docker Desktop，C 盘还剩 90 多个 G，我心想这下够用了。三个月后系统盘告急，打开空间分析工具一看，一个叫ext4.vhdx的文件吃掉了 40 多个 G，另一个docker_data.vhdx也不相上下。这就是我后来把整套环境从系统盘搬走的直接原因——不是洁癖，是被虚拟磁盘逼的。

先把概念摆正，不然后面所有操作都是照抄命令、看不懂原理。WSL2 跟你想象中的“Windows 内置 Linux 兼容层”完全是两码事：它是一个跑在 Hyper-V 之上的轻量级虚拟机，里面运行着真实的 Linux 内核。既然是虚拟机，就得有虚拟磁盘，微软用的是 VHDX 格式，文件名叫ext4.vhdx，存放在你的用户目录深处，默认路径大致是C:\Users\<你的用户名>\AppData\Local\Packages\<发行版包名>\LocalState\ext4.vhdx。这个文件会随着你装包、拉代码、编译项目一路膨胀，而且它是只涨不缩的——你删了文件，VHDX 内部的 Linux 文件系统确实腾出了空间，但宿主机上看到的那块虚拟磁盘大小并不会自动回落，得手动压缩。这一点是很多人误以为“我删了东西怎么还不释放空间”的根源。

Docker Desktop 同理。它现在的默认后端就是 WSL2，会额外创建两个专用发行版（老版本叫docker-desktop和docker-desktop-data，新版本把数据合并进了一个 VHDX 文件，直接由 Docker Desktop 管理），你拉下来的每一个镜像层、每一份容器写入数据，全都落在那个虚拟磁盘里。所以在 C 盘上同时养着 WSL2 发行版和 Docker 数据盘，等于养了两只会长大的气球。

那为什么不干脆一开始就把它们装到 D 盘？因为 Windows 这套东西的关键路径基本不受安装位置控制。WSL2 的发行版是走 Microsoft Store / 在线分发的，默认就往用户目录塞；Docker Desktop 的安装程序也不会问你数据放哪，得装完之后进设置里改。这就决定了比较靠谱的做法是先装好、跑通、再整体搬移，而不是一上来就折腾路径符号链接之类的偏门手法。硬要提前干预，只会让后续升级和排查变得极其难受。

这篇内容就是把我自己反复做过好几遍的完整流程摊开写：Win11 下装 WSL2、装 Docker Desktop、把两者的大文件全部迁到非系统盘、迁移后的收尾调优，以及一路上踩过的坑。适合两类人看——一类是刚接触容器、想在本机搭一套干净环境的；另一类是环境已经装好了但 C 盘快满、需要“无痛搬家”的。前者按顺序走一遍就行，后者可以直接跳到第 4、5 章。

2. 动手之前，三件必须先确认的事

2.1 硬件虚拟化与那两个 Windows 功能开关

这是最容易卡住新手的第一道门。WSL2 需要硬件虚拟化支持，具体是 CPU 的 VT-x 或 AMD-V，而且要在 BIOS/UEFI 里处于开启状态。查法很简单，任务管理器 → 性能 → CPU，右下角会显示“虚拟化：已启用”，或者干脆在 PowerShell 里跑一句systeminfo，翻到最下面找“Hyper-V 要求”那一节，四条全是“是”，才算合格。

功能层面，Win11 需要启用两个可选功能：虚拟机平台（VirtualMachinePlatform）和适用于 Linux 的 Windows 子系统（Microsoft-Windows-Subsystem-Linux）。现在的 WSL 版本在wsl --install时会自动帮你勾选，但如果你机器上有组策略限制、或者系统被精简过，自动勾选可能失败，那就老老实实用命令行手动开：

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

两条命令执行完必须重启。这里有个我踩过的坑值得单独说：有些机器上同时开着第三方虚拟化软件（比如安卓模拟器、虚拟光驱类工具），或者系统里残留着旧版 Hyper-V 的组件配置，会出现“功能开了但 WSL2 起不来”的情况，报错代码通常是0x80370102。这类问题的排查顺序是：先确认 BIOS 虚拟化是否真的开了，再看Hyper-V 虚拟机监控程序这项功能是否被意外禁用（注意 WSL2 本身并不要求完整开启 Hyper-V 管理器，但需要底层虚拟化平台可用），最后检查有没有安全软件拦截了虚拟机创建。

注意：开了虚拟机平台之后，部分老版本的虚拟机软件、模拟器会因为抢占虚拟化资源而变慢或无法启动，这是正常现象，不是系统坏了。

2.2 系统版本和 WSL 组件版本的“对齐”问题

Win11 的初始版本（21H2）自带的是 WSL 的早期版本，有些wsl --manage --move之类的新命令根本不存在，--import的参数也不一样。所以在装发行版之前，先更新 WSL 本体：

wsl --update wsl --version

wsl --version能正常输出（而不是报“无效参数”）就说明你用的是较新的独立版本 WSL。我建议把 WSL 更新到 2.0 以上，原因有二：一是原生支持--manage --move，可以把发行版目录直接移到别的盘，比导出再导入省一半时间；二是支持sparseVhd自动回收，也就是删掉文件后虚拟磁盘有机会自动瘦身，省掉手动压缩的麻烦。

顺带说明一个常被混淆的点：wsl --set-default-version 2设置的是“新建发行版默认用哪个版本”，不影响已存在的发行版。如果你之前装过 WSL1 的发行版，用wsl -l -v能看到每条的版本号，改的话是wsl --set-version <发行版名> 2。这步转换在数据量大的时候会跑很久，属于正常现象，别以为卡死了。

2.3 目标盘的选型和文件系统格式

选盘这件事，我见过太多人栽在这里。三个硬性要求：

检查项	要求	说明
文件系统	NTFS 或 ReFS	exFAT、FAT32 不支持 VHDX 的稀疏文件特性，迁移会直接报错
剩余空间	建议 ≥ 100 GB	虚拟磁盘上限受限于所在分区容量，别等到用满再搬
盘类型	优先 NVMe SSD	容器读写密集，机械盘上跑 Terraform 级别的构建会难受到怀疑人生

另外提醒一句：别把虚拟磁盘放到 OneDrive、坚果云这类同步目录下。同步客户端会去读这些大文件，造成频繁的文件锁冲突和疯狂上传，实测能让 WSL 直接卡死。也别放在移动硬盘或网络驱动器上，WSL 是通过底层虚拟化接口挂载 VHDX 的，非本地固定磁盘经常挂不上。

2.4 一个容易被忽略的前置动作：关掉正在跑的 WSL

后面所有的迁移操作，第一步都是wsl --shutdown。这句命令一定要养成习惯性执行的习惯，因为它会关掉所有发行版和 Docker 的后端。如果 Docker Desktop 还开着，wsl --shutdown之后它会愣在原地，容器全断，有时候还会自动拉起一半导致文件被占用，迁移到一半报“文件正在使用中”。正确顺序是：先退出 Docker Desktop（右下角托盘图标右键 → Quit Docker Desktop），等托盘图标消失，再wsl --shutdown，再确认wsl -l -v里所有发行版都是 Stopped 状态。

3. WSL2 的安装与首轮配置

3.1 一条命令装完，但参数值得挑一挑

最省事的装法就是打开 PowerShell（管理员），敲：

wsl --install

它会把功能开关、内核更新、默认发行版（通常是 Ubuntu 的某个 LTS 版本）一次性搞定，然后要求重启。但我更推荐带参数装，掌控感更强：

wsl --install --no-distribution

这句只装 WSL 本体和依赖，不装任何发行版。重启之后你再用wsl --list --online看看有哪些可选的，挑一个自己顺手的：

wsl --list --online wsl --install -d Ubuntu-22.04

这么做的理由很实际：默认发行版的版本不一定是你想要的，而且很多人第一次装完之后想换发行版，直接--unregister再重装，中间那些初始化状态就白跑了。分开装的好处是先有底座，再挑内容，后面迁移的时候也更清楚自己在搬什么。

发行版第一次启动会让你设置用户名和密码，这个用户名是你日常在 Linux 里登录的账户，密码是 sudo 密码，记牢。装完之后第一件事是sudo apt update && sudo apt upgrade -y，把包索引和基础组件拉到最新，尤其是 CA 证书和bash版本，后面 Docker 里各种走 HTTPS 拉镜像的操作都依赖这些。

3.2 systemd 要不要开，这是个实际问题

老版本 WSL 里是没有 systemd 的，所有服务都得手动起，很多人习惯性地用service xxx start。后来 WSL 支持了 systemd，配置方式是在/etc/wsl.conf里写：

[boot] systemd=true

改完wsl --shutdown再启动，systemctl status就能用了。要不要开？我的建议是：如果你的工作流里需要常驻服务（比如本地跑数据库、跑 CI 风格的构建、用 systemd 管理某些后台进程），就开；如果只是拿 WSL 当个命令行工具，跑跑 git、node、python，那开着也没坏处，但会多占一点内存。

这里还有一个必须配置的东西，就是默认登录用户。--import方式迁移过来的发行版，默认用户会变成 root，用起来各种别扭（家目录变了、SSH key 找不到、权限都是 root）。在/etc/wsl.conf里补一行就行：

[user] default=你的用户名

3.3 用 .wslconfig 给内存和 CPU 上个笼头

这一点很多人不知道：WSL2 默认会吃掉宿主机最多一半的物理内存，而且是动态伸缩的，跑大型编译的时候能让整个 Windows 卡成幻灯片。配置文件放在C:\Users\<你的用户名>\.wslconfig（注意是 Windows 用户目录下，不是 Linux 里面），新建后用文本编辑器写：

[wsl2] memory=8GB processors=4 swap=2GB swapFile=D:\\wsl\\swap.vhdx localhostForwarding=true sparseVhd=true

参数含义掰开说：memory是硬上限，16G 内存的机器给 8G 比较合适，32G 的可以给到 12～16G；processors是虚拟 CPU 数，别超过物理核心数，不然调度反而变慢；swap是交换分区大小，编译大项目的时候给 2～4G 能救命；swapFile把它也放到非系统盘，省 C 盘空间；localhostForwarding让 Windows 侧可以直接用localhost:端口访问 WSL 里的服务，这条几乎是必开的，不然你本地跑个 Web 服务还得去查 WSL 的 IP。

还有一个较新版本才支持的autoMemoryReclaim=gradual，作用是空闲一段时间后把 WSL 占的内存还给 Windows。老版本机器上这条可能不生效，不生效就直接删掉，别留着，某些版本上写了不认识的键会让整个配置文件被忽略——这个坑我吃过一次，改了配置半天没反应，查了半天才发现是某一行参数名写错了导致全文件失效。

4. 把 WSL2 发行版搬到非系统盘

4.1 先弄明白：迁移的本质是搬一个虚拟磁盘

很多人以为迁移就是把文件夹剪切粘贴过去，这是绝对不行的。WSL 的发行版不是一个普通目录，它在系统里注册了 GUID、路径、默认用户、版本号等元数据，你手动移动目录，注册表里的路径还指着老地方，结果就是发行版直接消失。

正确的做法有两条路：

路线 A：wsl --manage --move（推荐，WSL 2.0 以上）。一条命令搞定，WSL 自己处理注册信息和文件搬移，最省心。

路线 B：export+unregister+import（通用，任何版本可用）。把整个发行版打包成一个 tar 文件，注销旧发行版，再从 tar 文件导入到新位置。步骤多，但可控性强，tar 文件还可以当作备份留着。

两条路的共同前提都是：先wsl --shutdown，所有发行版停干净。下面是路线 B 的完整操作，因为它的兼容性最好，也最能体现原理。

4.2 完整迁移步骤与参数含义

第一步，列出所有发行版，确认名字和版本：

wsl -l -v

输出里NAME那一列就是后续命令要用的标识，大小写和空格都要对。假设叫Ubuntu-22.04。

第二步，导出。目标路径选在空间充足的盘上，tar 文件大小通常和原 vhdx 差不多，甚至更大一点（tar 不做压缩的话）：

wsl --export Ubuntu-22.04 D:\wsl-backup\ubuntu2204.tar

这一步的耗时跟数据量强相关，几十 G 的发行版跑十几分钟很正常，中间别关窗口。如果嫌文件太大，可以先用wsl进去清理一下缓存（sudo apt clean、删掉~/.cache），能省下不少体积。

第三步，注销旧发行版：

wsl --unregister Ubuntu-22.04

注意：--unregister会永久删除该发行版及其全部数据，包括你的家目录。执行前确认 tar 文件已经完整生成，最好用dir D:\wsl-backup\ubuntu2204.tar看一眼文件大小不是 0。

第四步，导入到新位置：

wsl --import Ubuntu-22.04 D:\wsl\ubuntu2204 D:\wsl-backup\ubuntu2204.tar --version 2

三个参数分别是发行版名字、新的安装目录（VHDX 会放在这里）、tar 文件路径。安装目录必须是空目录，或者不存在让 WSL 自己创建，提前建好一个带其他文件的目录会报错。--version 2显式指定 WSL2，避免某些环境下默认回落到 WSL1。

第五步，恢复默认用户。前面说过，导入之后默认用户是 root，改/etc/wsl.conf：

wsl -d Ubuntu-22.04 -u root

进去之后编辑/etc/wsl.conf：

[user] default=你的用户名

保存退出，wsl --shutdown，再启动就恢复正常了。这一步不做的话，你会发现家目录是/root，之前装的所有东西、配的 SSH key 全“不见了”——其实没丢，只是换了用户。

4.3 迁移后的验证清单

搬完别急着删 tar 文件，先做这几项确认：

验证项	操作	期望结果
发行版列表	wsl -l -v	状态 Running/Stopped，版本 2
默认用户	whoami	你的用户名，不是 root
家目录数据	ls ~	之前的项目文件和配置都在
网络连通	curl -I https://…	能正常返回响应头
新位置文件	查看D:\wsl\ubuntu2204	有ext4.vhdx，且体积合理

全部通过之后，再删掉中间那个 tar 文件。我个人的习惯是留一份 tar 当“冷备份”放一两周，确认新环境稳定再清，毕竟--unregister是不可逆的，多留一手成本很低。

如果你用的是路线 A，命令就一行：

wsl --manage Ubuntu-22.04 --move D:\wsl\ubuntu2204

它会自己完成停机、搬移、重新注册的全过程。缺点是没有中间产物做备份，所以我对重要数据的发行版还是习惯走导出导入。另外这条命令要求目标目录不存在或为空，磁盘空间要够（因为它内部也是复制一份）。

5. Docker Desktop 的安装与数据盘迁移

5.1 安装时的两个关键勾选项

从官网下载 Docker Desktop 安装包，双击运行。安装向导里有两个选项值得留意：

• Use WSL 2 instead of Hyper-V：Win11 上默认就是这个，保持勾选。选择 WSL2 后端的好处是启动快、资源占用低、能和你的 WSL 发行版共享网络与文件。
• Add shortcut to desktop / Enable WSL integration：前者随意，后者要勾。

装完重启（有些机器不重启也行，但 Docker 第一次启动会初始化 WSL 后端，重启更稳）。启动后右下角出现小鲸鱼图标，第一次会弹服务条款，接受即可。如果提示“WSL 2 installation is incomplete”，说明 WSL 内核更新没到位，回到第 2 章跑一次wsl --update。

还有个细节：安装完成后wsl -l -v会多出一到两个以docker-desktop开头的发行版。新版 Docker Desktop 里，数据集中放在一个由 Docker 自己管理的 VHDX 文件里，位置默认在C:\Users\<用户名>\AppData\Local\Docker\wsl\下面，那个docker_data.vhdx（或类似名字）就是罪魁祸首之一。

5.2 用图形界面把数据盘位置改掉（最省事）

这是官方支持的正规路径，也是我最推荐的方式。步骤：

1. 确保 Docker Desktop 完全退出（托盘右键 → Quit）。
2. 在目标盘建好目录，比如D:\docker-data。
3. 打开 Docker Desktop → 右上角齿轮Settings→ 左侧Resources→Advanced。
4. 找到Disk image location，点Browse，选到D:\docker-data。
5. 点Apply & restart。

Docker 会自己把现有的数据搬过去，界面上有进度提示。数据量大时这个过程会持续几分钟到十几分钟，期间别去手动关进程。

在这里顺便把资源限额也调一下，同一个Advanced页面里，CPU 和内存的上限设置对 WSL2 后端其实影响有限（真正的上限由.wslconfig控制），但Virtual disk limit值得设置，比如给 128GB，避免容器日志无限增长把盘吃满。

5.3 手工迁移 docker-desktop 发行版（界面搬不动时的备用方案）

有些情况下图形界面改位置会失败，报一个含糊的错误，或者卡在“Moving…”不动。这时候就得回到命令行，思路和迁移普通发行版一样，只是要处理两个特殊发行版。

先看清单：

wsl -l -v

老版本会有docker-desktop（跑引擎）和docker-desktop-data（存数据）两个。新版本通常只剩一个docker-desktop，数据由 Docker 通过docker_data.vhdx管理，这时候命令行迁移的意义就不大了，老老实实排查界面为什么失败（常见原因是目标盘空间不足、目录权限不对、或者上一次迁移留下的临时文件没清）。

如果确实是双发行版的旧结构，操作如下：

wsl --shutdown wsl --export docker-desktop-data D:\docker-backup\ddd.tar wsl --unregister docker-desktop-data wsl --import docker-desktop-data D:\docker\data D:\docker-backup\ddd.tar --version 2

注意：docker-desktop-data这个发行版是 Docker 自己管理的，手工迁移之后不要再去wsl里登录它、改它的默认用户，任何定制都可能让 Docker 启动时自检失败，表现为小鲸鱼一直转圈然后提示引擎停止。

数据搬完之后再启动 Docker Desktop，如果它报错说找不到数据，可以尝试Settings → Troubleshoot → Restart，或者干脆Reset to factory defaults重新拉镜像——当然那只在你不心疼已有镜像的情况下才用。

5.4 一个更干净的思路：项目文件全部放进 WSL

迁移完数据盘，还有个隐形的 C 盘消耗大户：你在 Windows 侧建的项目目录，通过/mnt/c/...被 WSL 访问。这种方式下文件 I/O 要经过一层跨系统文件共享（早期是 9p 协议，新版做了优化但仍然比原生慢一个数量级），而且容器里挂载这些路径做编译时，性能能差出好几倍。更麻烦的是符号链接和文件权限经常对不上。

我现在的习惯是：代码仓库全部放在 WSL 的家目录里（~/projects/xxx），用 VS Code 的 Remote-WSL 打开，编辑体验和本地没区别，但编译速度和权限问题一次性解决。这也间接省掉了 C 盘上一大批node_modules、target、build目录的空间。

6. 迁移后的收尾：空间回收与性能调优

6.1 VHDX 只涨不缩，压缩得手动来

前面提过这个特性，这里给具体做法。虚拟磁盘文件删除内部数据后不会自动缩小，得用工具压缩。Windows 自带的diskpart就能干，步骤稍微绕：

wsl --shutdown diskpart

进去之后依次执行：

select vdisk file="D:\wsl\ubuntu2204\ext4.vhdx" attach vdisk readonly compact vdisk detach vdisk exit

compact vdisk就是真正干活的那句，执行时间跟文件大小有关，几十 G 的文件跑几分钟。跑完再看文件属性，通常能缩回去 30%～60%。这个操作我一般一个月做一次，或者在跑完一个大型构建、清掉一堆容器镜像之后顺手来一发。

如果你用的是较新版 WSL，还有个更省事的路子：wsl --manage <发行版> --set-sparse true，开启稀疏文件后，删除的数据有机会自动回收。但要注意稀疏文件在某些备份软件、云同步工具处理时会出问题，我个人的做法是默认不开自动稀疏，定期手动压缩，可控性更好。

6.2 迁移后常见的路径与权限问题

搬到 D 盘之后，有几个细节会跟以前不一样，值得提前知道：

跨盘访问变慢了吗？不会。WSL 访问自己所在盘的 VHDX 是走虚拟化层，跟物理位置无关。真正影响性能的是访问/mnt/c、/mnt/d这类宿主机路径，跟 VHDX 放哪个盘没关系。

软链接会不会断？Windows 侧的符号链接指向旧路径的会断，WSL 内部创建的 Linux 符号链接不受影响，因为它记录的是 Linux 内的相对/绝对路径。

备份工具要注意。某些备份软件在处理 VHDX 时会把它当作普通大文件处理，每次全量备份几十 G 很浪费。我一般把D:\wsl和D:\docker-data排除在常规备份之外，需要备份时用wsl --export单独导一份，既省空间又能保留完整状态。

盘符变动会要命。如果你的 D 盘是外接硬盘或者动态分配的盘符，某次开机变成 E 盘，WSL 就找不到虚拟磁盘了，表现是所有发行版消失。这种情况的补救办法是重新执行--import到新路径，或者用磁盘管理把盘符改回去。所以我一般建议把 WSL 和 Docker 的数据盘固定成一个内置的、盘符不会变的固态分区。

6.3 把 Docker 的构建缓存也管起来

Docker 自己也有个吃空间的习惯：构建缓存。docker system df能看到分项占用，经常是 Images 还好，Build Cache 占了好几 G。定期清理：

docker system prune -a --volumes

这条会删掉所有未被使用的镜像、容器、网络和卷，属于“核弹级”清理，用之前确认没有靠停止状态保活的容器。温和一点的话用docker builder prune --filter until=168h，只清 7 天前的构建缓存。

Docker Desktop 里也有图形入口：Settings → Resources → Advanced → Disk usage，能看到当前占用，也可以在这里触发清理。我个人更习惯命令行，因为输出更明确。

7. 报错与排查速查表

7.1 安装阶段：虚拟化与内核问题

现象	大概率原因	处理方式
WslRegisterDistribution failed with error: 0x80370102	硬件虚拟化未开，或虚拟机平台功能未启用	进 BIOS 开 VT-x/AMD-V，再检查VirtualMachinePlatform功能状态
WSL 2 requires an update to its kernel component	内核更新包缺失	wsl --update，失败则手动下载安装包
0x800701bc	老版本 WSL 内核不匹配	同上，更新后wsl --shutdown重启
Docker 提示 WSL 2 installation is incomplete	Docker 检测不到合规的 WSL2	先跑通wsl -l -v能正常输出，再重启 Docker
--install卡在下载	网络问题或 Store 服务异常	改用wsl --install --no-distribution后手动装发行版

关于0x80370102，我补充一个不太常见但真实的成因：机器上装过某些虚拟化平台后卸载不干净，残留的虚拟交换机配置会让 WSL 无法建立虚拟网络。这种情况下Hyper-V 管理器里能看到一堆孤立的虚拟交换机，清理掉往往就好了。

7.2 迁移阶段：路径、权限、占用

现象	大概率原因	处理方式
The system cannot find the path specified	目标目录不存在或含特殊字符	用纯英文路径，比如D:\wsl\ubuntu2204
The process cannot access the file	Docker 或发行版还在运行	退出 Docker Desktop，wsl --shutdown后再操作
导入后默认用户变 root	/etc/wsl.conf未配置	加[user] default=xxx，重启
迁移后网络不通	DNS 配置残留	wsl --shutdown重启；必要时检查/etc/resolv.conf
虚拟磁盘挂不上	目标盘是 exFAT/网络盘	换到 NTFS 本地固定磁盘

路径这一条值得多说两句。WSL 的命令行对路径的处理有时候很微妙，含中文字符、空格、&符号的路径容易出问题，尤其是--import的目标目录。我的建议是：所有 WSL 相关目录一律用纯英文、无空格、层级浅的路径，比如D:\wsl\、D:\docker-data\。省下的排查时间远超你起名字时的那点纠结。

7.3 运行阶段：性能与网络

现象	排查方向
容器内编译极慢	项目是否放在/mnt/c下，搬到~/里再试
WSL 内存越吃越多不释放	检查.wslconfig是否生效，考虑开autoMemoryReclaim
宿主机访问不了 WSL 服务	确认localhostForwarding=true，或直接用 WSL IP
Docker 启动后占用几个 G 内存不动	引擎本身 + 镜像索引的固定开销，属正常，可调小内存上限
磁盘占用只增不减	VHDX 未压缩，按 6.1 节处理

.wslconfig是否生效有个快速验证法：改完之后wsl --shutdown，再启动，进去跑free -h和nproc，看内存总量和 CPU 数是不是你设的值。如果没变，八成是文件放错位置了——它必须在 Windows 用户目录下（C:\Users\<名字>\.wslconfig），不是 Linux 里的~/.wslconfig，这个混淆我看到过太多次。

8. 我踩过的坑和长期维护的几个习惯

先说印象最深的一次事故。给一台笔记本迁 WSL 发行版，导出 tar 之后执行--unregister，然后--import的时候手滑把目标目录写成了 tar 文件所在的目录，结果 WSL 在里面创建 VHDX 时把 tar 文件跟自己搞到了同一个目录，后来我清理临时文件的时候顺手把整个目录删了，虚拟磁盘和备份一起没了。教训很直接：导入目录和备份文件目录必须分开，而且备份文件在验证完成之前不要动。现在我的固定布局是D:\wsl\<发行版>\放运行数据，D:\wsl-backup\放 tar，两个目录物理隔离，清理时永远不会误伤。

第二个坑跟 Docker 的图形界面迁移有关。有一次在 Settings 里改 Disk image location，点了 Apply 之后界面一直转圈，我等得不耐烦强制关了进程，结果 Docker 处于半迁移状态：老的 vhdx 还在，新的目录里有个不完整的文件，启动时报“引擎无法启动”。最后的解法是删掉新目录里的残留文件，重新启动 Docker 让它回退到旧位置，然后再迁移一次，这次耐心等它跑完。所以我的建议很简单：点完 Apply 之后去泡杯茶，别碰它，界面卡住不代表没在动，后台在复制几十 G 的数据。

第三个是内存。有段时间我的机器频繁出现整个系统假死，任务管理器里显示 WSL 占了 20 多 G。原因是.wslconfig里我把 memory 设成了 24GB，而机器总共 32GB，Windows 自己也要吃饭。后来改成 12GB，再加autoMemoryReclaim=gradual，情况明显好转。这件事让我形成了一个习惯：给 WSL 的内存上限，不超过物理内存的 60%，剩下的留给宿主系统和 Docker。

日常维护上，我现在固定做三件事：

第一，每个月跑一次 VHDX 压缩，两个盘都压（WSL 的和 Docker 的），通常能回收十几 G。

第二，docker system df看一眼，Build Cache 超过 10G 就清，镜像超过 30 个就把不用的删掉。这里有个小技巧：给常用镜像打个明确的 tag，清理时用docker image prune -a --filter "until=720h"只删两周以上没被引用的，避免误删。

第三，每季度用wsl --export导一份完整备份放到另一块盘上。这份备份不常用，但在我遇到过的一次虚拟磁盘损坏里救了大命——那次是断电导致 vhdx 文件系统损坏，wsl启动直接报错，导出的 tar 重新 import 之后就恢复了，损失的只是几天的增量。

最后分享一个我觉得很值的小设置：把 WSL 发行版和 Docker 的数据目录都放到同一块非系统盘上，然后在资源管理器里给D:\wsl加个快捷方式到任务栏。这样每次想看看虚拟磁盘长多大了，一点就开，比在深层目录里翻要顺手得多。空间这种事，看得见才管得住。