上周把服役四年的老机器拆了换了一台新的顺手把系统盘从 512G 换成 2T。Windows 那边用整盘克隆的方式搬过去开机、登录、常用软件全都在桌面壁纸都没变。看起来一切正常直到我在新机器上打开终端敲下wsl -l -v屏幕上干干净净一行输出都没有。三个发行版、两年的 dotfiles、几十个 Python 虚拟环境、还有一整个本地模型的权重目录全都在那台数据还在的旧盘里躺着。更麻烦的是我当时并没有在新机器上立刻发现这件事——因为我习惯用 VS Code 的 Remote 连接开发环境直到项目跑不起来才反应过来。这篇记录写的就是从那次翻车开始把 WSL2 的整套环境从旧机器或者旧盘完整搬到新机器上的全过程迁移前要盘清楚哪些东西属于WSL2 系统导出时该用哪种方式导入后第一个小时必须做的自检有哪些以及网络、Docker、CUDA、SSH 这些容易在新环境里集体失联的模块怎么重新挂钩。如果你正准备换机器、换固态、或者只是想把 WSL2 挪到容量更大的分区上可以直接照着这份记录抄能省掉我返工三次的时间。1. WSL2 的系统到底存在哪儿先把要搬的东西点名1.1 发行版不是 C 盘里一个文件夹那么简单大部分人第一次迁移都会犯同一个错以为 WSL2 的发行版就是一个装在某个目录下的虚拟机文件复制过去就能用。实际情况是两层结构拼起来的。第一层是数据层。Store 方式安装的发行版根文件系统放在一个ext4.vhdx里默认路径大约长这样C:\Users\用户名\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu22.04LTS_79rhkp1fndgsc\LocalState\ext4.vhdx这个路径里那串79rhkp1fndgsc是包家族名Package Family Name的哈希每种发行版、每个发布版本都不一样。你装的是 Ubuntu 22.04 还是 Ubuntu 24.04目录名完全不同。而且如果你通过wsl --import手工导入过发行版它压根不在Packages目录下而是在你指定的那个安装位置。第二层是注册信息层。WSL 靠注册表里的一棵子树来认领这些 vhdxGet-ChildItem HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss每个发行版是这棵树下的一个 GUID 子键里面有BasePath发行版根目录、DistributionName显示名、Flags版本标志WSL1/WSL2 就藏在这、DefaultUid默认登录用户、State等字段。wsl -l -v能列出什么完全取决于这棵树里有什么而不是取决于磁盘上有没有 vhdx。这就解释了克隆迁移翻车的根本原因整盘克隆工具擅长搬文件但不一定搬注册表项与文件路径的对应关系。更常见的情况是注册表搬过来了BasePath还写着C:\Users\oldname\AppData\Local\Packages\...而新机器的用户名是newname或者盘符从C:变成了D:于是 WSL 找不到 vhdx直接表现为发行版不存在或启动时报一句莫名其妙的错误。1.2 整盘克隆之后 WSL2 常常消失的几种真实原因我这次的现场表现是wsl -l -v完全空。后来逐一排查能归到下面几类现象实际原因处理方向wsl -l -v完全空注册表 Lxss 子树没跟着克隆或克隆后被新系统的 Store 重新注册覆盖重新 import不要试图修注册表列表里有但启动报错BasePath指向的盘符/用户名在新机器上不存在重新 import 到新路径列表里有进去是全新系统Store 应用重装把LocalState目录重建了旧的 vhdx 被换掉从旧盘里找未被覆盖的 vhdx完全连子系统功能都没有虚拟化平台、子系统功能未启用或内核组件缺失先修 Windows 侧开关报虚拟化未启用固件里 VT-x/AMD-V 被关或与 Hyper-V、内存完整性冲突BIOS 与系统设置层面处理把这些原因排一遍你会发现整盘克隆这条路本身就不适合搬 WSL2。它适合把操作系统、驱动、桌面软件一次性搬过去因为那些东西靠安装信息就能自我修复WSL2 的数据和身份注册是分离的任何一环对不上就得重来。真正稳的迁移方式是在旧环境里把发行版导出成一个自包含的文件在新环境里重新注册。这样你不依赖任何克隆工具的兼容性也不关心盘符和用户名怎么变。1.3 迁移前先做一次体检三条命令摸清家底动手之前先在旧机器或者旧盘引导起来的系统里把下面这些信息记下来写进一个文本文件存到移动介质上。这一步花五分钟能省掉后面一小时的猜谜。# 1. 发行版清单与版本注意 State 和 VERSION 列 wsl -l -v # 2. WSL 本身的版本决定你有哪些新参数可用比如 --vhd、--set-sparse wsl --version # 3. 每个发行版实际的存储路径第三条在 PowerShell 里跑Get-ChildItem HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss | ForEach-Object { $p Get-ItemProperty $_.PSPath {0,-24} {1,-6} {2} -f $p.DistributionName, $p.Version, $p.BasePath }在 Linux 侧还要把这几项当成户口信息记下来导入之后要逐一核对id -u和id -g当前用户的 UID/GID。默认通常是 1000但只要你以前usermod -u改过就不是 1000导入后必须对齐。getent passwd 用户名确认 home 目录路径有些人把 home 改到了/data/xxx这个不记下来导入后会很别扭。sudo -l或groups确认自己在哪些组里docker、sudo、adm这些组权限如果丢了后面会出现命令存在但没权限的诡异现象。cat /etc/wsl.conf这个文件是 WSL 特有的行为开关不导出到外部记录的话导入后所有默认行为都会回到出厂状态包括默认用户变成 root。另外提醒一句.wslconfig文件在 Windows 侧路径是%UserProfile%\.wslconfig它管的是内存上限、处理器数量、网络模式这些全局参数跟发行版无关所以不会跟着导出走必须单独备份。2. 新机器的地基Windows 侧先把 WSL2 环境立起来2.1 两个开关和一次版本声明新系统装好之后不要急着导入发行版先把地基检查一遍。WSL2 依赖的前提条件有两类一类是 Windows 功能开关一类是虚拟化能力。功能开关通过启用或关闭 Windows 功能面板或者用命令行更直接。管理员权限的 PowerShell 里dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart前者是子系统接口本身后者是 WSL2 依赖的轻量虚拟化层。两条命令跑完必须重启不要跳过——我见过有人跳过重启直接wsl --install最后卡在安装阶段以为网络问题排查了半小时。重启之后确认默认版本然后更新一次内核组件wsl --set-default-version 2 wsl --updatewsl --set-default-version 2的作用是让后续所有--import和商店安装默认落到 WSL2 上。这个设置在新系统上是必须显式做的因为默认值在某些版本里仍然是 1。wsl --update走的是微软自己的更新通道网络状况不好时确实会很慢我会在下一节讲怎么绕。这一步很重要因为很多新参数--export --vhd、--manage --move、--manage --set-sparse都是较新版本才有的。如果你后面执行命令时提示无法识别的参数八成是这里的版本太老。硬件虚拟化这一层在任务管理器性能 → CPU里看右下角有没有虚拟化已启用。显示已禁用就进固件设置打开。另外要注意两个容易被忽略的冲突点系统里同时启用了 Hyper-V 相关组件和某些安全功能如内存完整性时个别版本会出现 WSL2 启动失败报的错还偏偏是未启用虚拟化非常有误导性。遇到这种报错先按提示检查固件其次看系统安全设置最后再怀疑 WSL 本身。2.2 网络不通时的离线思路我这次是在一个网络受限的环境里做迁移wsl --update和商店下载都跑不动。这种时候有两条备用路。第一条是把内核更新包和WSL 本体安装包提前从能联网的机器上下载好带过来直接双击安装装上之后再离线导入发行版。第二条更彻底也是我更推荐的做法完全不依赖商店直接用发行版官方的根文件系统包 wsl --import。Ubuntu 官方会发布面向容器和云环境的根文件系统压缩包下载下来之后在新机器上执行wsl --import Ubuntu-22.04 D:\WSL\Ubuntu-22.04 D:\download\ubuntu-22.04-rootfs.tar.gz --version 2这条命令的语义要拆清楚第一个参数是你要给这个发行版起什么名字第二个参数是数据放在哪第三个参数是根文件系统来源。它不需要商店、不需要联网、不挑发行版版本而且和从旧机器导出的 tar 用的是完全同一套机制。换句话说你从旧机器导出的那个 tar本质上就是一个你自己的定制根文件系统。同一个 HTTP 界面能装官方原版也能装你自己养了两年的环境这就是为什么这条迁移路线最可靠。2.3 Ubuntu 22.04 还是 24.04迁移场景下的取舍迁移时有一个决策点容易被忽略要不要顺手升级发行版大版本。我的建议是这次迁移不要顺带升级。理由很实在。迁移本身已经在动默认用户、网络模式、权限挂载、Docker 集成、GPU 库路径这一串状态任何一个地方出问题你都要花时间定位。如果同时把 22.04 换成 24.04那出问题时你面对的变量是两个是迁移没做好还是升级引入的兼容性问题排查成本直接翻倍。正确的顺序是先把 22.04 原样搬过来跑通、验证、稳定运行一两周再单独规划一次系统升级。真要升级也应该是do-release-upgrade这种原地升级而不是重新 import 一个 24.04 然后手动搬环境。当然如果你本来就是全新开始那么 CentOS 系的替代品或者 Ubuntu 24.04 都值得选特别是新版本对 systemd 支持、cgroup 版本、以及新版 CUDA 工具链的兼容性更好。但这是新建而不是迁移的话题两件事别混在一起做。3. 旧机器上的打包动作export 到底导出了什么3.1 tar 导出与 vhdx 导出两条路差别很大WSL 提供两种导出方式很多人随便挑一个用然后在导入时才发现不匹配。对比项wsl --exporttarwsl --export --vhdvhdx产物本质根文件系统的归档整块虚拟磁盘镜像体积接近实际占用天然不带空洞含空洞往往比实际占用大跨机器兼容性很好与新机器盘符、用户名无关一般对 WSL 版本和宿主环境更敏感能否瘦身导一遍再导回来等于瘦身不瘦身空洞照搬导入命令wsl --import ... --version 2wsl --import --vhd适用场景换机器、换系统、跨大版本同机快速复制、磁盘布局要保持一致我的选择很明确跨机器迁移一律用 tar。因为它把文件和磁盘解耦了新机器上不管你的盘符是 D 还是 E、用户名变没变导入之后都是一套干净的新 vhdx。而且 tar 只包含文件数据那些被删除但尚未回收的空洞不会被打包等于免费瘦身一次。顺便说一个很多人不知道的省事办法如果你只是想把发行版从 C 盘挪到 D 盘根本不需要导出导入直接用较新版本提供的迁移参数wsl --manage Ubuntu-22.04 --move D:\WSL\Ubuntu-22.04先wsl --shutdown停掉所有实例再执行它会自动搬运并更新注册信息。这个参数在旧版本里没有所以前面让你确认wsl --version就是这个原因。3.2 大文件搬运的几个实操细节导出的命令本身很简单但有几个细节决定了你会不会白等两小时。# 导出前先彻底停掉避免打包到一半文件被写入 wsl --shutdown # 逐个发行版导出路径尽量放在空间充足的数据盘 wsl --export Ubuntu-22.04 D:\backup\ubuntu-22.04-20240601.tar第一个细节是先 shutdown。wsl --export会拿文件系统的快照理论上不关机也能跑但如果导出期间有进程在写数据tar 里可能出现不一致的内容。我这次导出的是一个跑着数据库的开发环境第一次没关机导入后数据库报了一堆校验错误。虽然不一定是关机导致的但从那以后我导出前一律 shutdown图个心安。第二个细节是校验。导出完成后立刻算一次哈希并且记录文件大小Get-FileHash D:\backup\ubuntu-22.04-20240601.tar -Algorithm SHA256拷到新机器之后用同样的算法再算一次两个哈希必须一致。如果中间经过了移动硬盘、U 盘、或者网络传输这一步绝对不能省。我踩过一次坑拷贝过程中硬盘掉了一下文件大小正常但哈希对不上导入之后有几百个文件损坏症状是系统能启动但随机命令找不到非常难排查。第三个细节是压缩与分卷。如果你有多个发行版或者 home 目录里有大量小文件导出的 tar 有几个 GB 到几十个 GB 都很正常。想省空间可以外部压缩tar -cf - -C /path | zstd -19 -o ubuntu-22.04.tar.zst不过要注意导入时需要先解压回 tar 再用或者用支持流式解压的管道方式。如果你的目标是尽快搬完那么压缩省下的传输时间不一定能抵掉压缩本身的时间用哪个级别的压缩看你手上的硬盘速度具体是多少。第四个细节是目标盘的文件系统。tar 文件可能在单个文件里就超过 4GB目标分区不能是老的 FAT32。用 U 盘转存时尤其注意很多出厂格式化的 U 盘还是 FAT32拷到一半报文件过大。3.3 顺手把 Windows 侧那几份隐形配置抄下来导出只负责发行版内部的数据。Windows 侧还有一批配置不备份的话新机器上要重配一遍。清单不长但每一项都很烦人%UserProfile%\.wslconfig内存上限、处理器数量、交换文件、网络模式、DNS 行为。这个文件没了你会发现新机器的 WSL 一上来就吃掉一半内存。Windows Terminal 的settings.json配置文件的路径可以从终端设置界面的打开 JSON 文件找到。它保存的是所有 profile 定义、默认发行版、字体、配色、启动目录。新机器上重配一遍至少要二十分钟。Docker Desktop 的设置特别是 WSL 集成里勾选了哪些发行版、镜像数据是不是放在独立磁盘上。如果以前把 Docker 数据放在了专门的 vhdx 里那个文件也要单独备份。VS Code 的远程开发配置settings.json里的remote.WSL相关项、以及.vscode-server目录。后者其实在 Linux 侧的 home 里跟着 tar 走不用单独备份。你放在 Windows 侧的 SSH 私钥、known_hosts、以及自定义的 SSH 配置。从 Windows 侧连 WSL 的场景里这些很关键。把这些文件统一拷到一个migrate/目录和 tar 包放在一起。后面导入完成后逐个放回原位比重新配置快得多。4. 新机器上的导入一个参数不对就白干4.1--import的三个参数和它们真正决定的东西导入命令长这样wsl --import Ubuntu-22.04 D:\WSL\Ubuntu-22.04 D:\backup\ubuntu-22.04-20240601.tar --version 2三个参数分别对应叫什么名字放哪儿从哪儿来。看起来简单但每个参数都有坑。名字。导入后的名字和原机器上的名字可以不同。如果你打算把新旧两个发行版并存对比那就换个名字如果只想替换就沿用原名。但要注意同名冲突如果新系统里已经有一个同名发行版比如你手滑先装了一个商店版导入会失败或覆盖先wsl --unregister 名字清掉再导。安装位置。这个目录会成为新 vhdx 的父目录WSL 会在里面创建ext4.vhdx和一两个辅助文件。两个建议第一放在专用目录里比如D:\WSL\Ubuntu-22.04不要直接扔在盘根目录第二不要放在被云盘同步或实时备份软件监视的目录里。我第二次迁移时把目录放错了那个目录被一个同步客户端盯着结果 vhdx 被反复扫描和加锁WSL 启动时好时坏报错信息还完全指不到方向。排查了两小时才想到是同步软件的问题。来源。这里是 tar 还是 vhdx必须和--vhd参数匹配否则报错。另外如果你的 tar 是被压缩过的比如.tar.zst或.tar.gzwsl --import不认识这些格式要先解压成裸 tar。Windows 上解压大文件建议用支持流式的工具避免解压出来占用双倍空间。导入过程本身没有任何进度输出屏幕上就一个光标闪啊闪。这是最考验人的一段你会怀疑它卡死了。判断方法很简单打开任务管理器看磁盘写入速度只要还有几百 MB/s 的写入就说明在干活。我导一个 40GB 的 tar 花了大约七分钟期间我差点按 CtrlC 三次。4.2 导入后第一件事不是敲代码是修默认用户导入完成后wsl -l -v能看到新发行版了但一进去你会发现提示符是root机器名。这不是故障而是设计使然wsl --import不携带原来的默认用户设置注册信息里的DefaultUid是 0。修法的推荐路径是在发行版内写/etc/wsl.conf[user] defaultyourname [automount] enabled true options metadata,umask22,fmask11 [boot] systemd true [interop] enabled true appendWindowsPath true [network] generateResolvConf true [hostname]写完之后回到 PowerShell 执行一次终止让配置生效wsl --terminate Ubuntu-22.04重新进去提示符就变回你的普通用户了。这里有个必须检查的点UID 是否对得上。tar 里保留的是数字 UID如果你的旧环境用户是 1000导入后/etc/passwd里也还是 1000那没问题。但如果你在新机器上曾经手工建过一个用户或者旧环境里改过 UID就可能错位。检查方式id -u yourname ls -ln /home如果 home 目录属主显示为1001而你的 UID 是1000那所有文件你都没有写权限。修法sudo usermod -u 1000 yourname sudo groupmod -g 1000 yourname sudo chown -R yourname:yourname /home/yourname不建议直接手改注册表里的DefaultUid虽然那样也能生效但很容易在后续操作中被覆盖而且不方便版本控制和迁移。写wsl.conf是更干净的方式。4.3 权限、挂载与那些默认值的变化/etc/wsl.conf里那几行不是装饰每一项都对应一个具体的日常痛点。[automount] options metadata,umask22,fmask11没有metadata的时候/mnt/c下所有文件的权限都是固定的一刀切chmod不起作用。表现是git报文件模式变了ssh报私钥权限太开放然后拒绝使用。加上这个选项之后Linux 侧的权限可以正常读取写入跨系统项目的问题少一大半。[boot] systemd true如果你的发行版本身支持较新的 Ubuntu 默认镜像就带打开之后systemctl才可用Docker、SSH 服务才能开机自启。注意这个开关只在较新版本 WSL 里支持。[interop] appendWindowsPath true把 Windows 的 PATH 追加上来这样你在 Linux 里能直接调code、explorer.exe。但如果你做的是性能敏感的编译任务PATH 里塞几百个 Windows 目录会让补全变慢这种情况可以关掉。[network] generateResolvConf true决定 WSL 是否自动生成/etc/resolv.conf。这个开关和后面的网络问题强相关后面单独说。还有一点这些配置是全局默认行为的一部分导入的 tar 里带着你在旧机器上写的wsl.conf所以理论上你不需要重写。但每次迁移我都建议打开确认一遍因为有些配置是当年为了解决某个特定问题临时加的新环境里未必还需要甚至可能有害。5. 落地后的自检清单按顺序过一遍别跳导入完成、默认用户修好这只能算能进去。真正能不能干活取决于下面这几项。我按重要性排了个顺序逐项过一遍大概十分钟能省掉后面几小时的困惑。序号检查项验证命令常见异常1网络与 DNScurl -I https://example.com、apt update域名解析失败、apt 卡住2systemd 状态systemctl is-system-running返回 offline 说明没启用3跨系统挂载权限在/mnt/c/tmp建文件并chmod权限不生效、git 报模式变化4Docker 集成docker info、docker context ls找不到守护进程5GPU 可见性ls /dev/dxg、nvidia-smi设备不存在、驱动版本不匹配6SSH 服务systemctl status ssh端口未监听、连接被拒7时间同步date与 Windows 时间对比偏差数小时导致证书校验失败8磁盘占用df -h、Windows 看 vhdx 大小空间对不上、只涨不缩5.1 网络与 DNS从 NAT 到镜像模式的取舍新环境里最常出问题的就是这一块。默认网络模式是 NATWSL 从 Windows 借一个虚拟网段/etc/resolv.conf由 WSL 自动生成指向虚拟网关。这套机制在大部分场景能用但有两个典型毛病一是 Windows 侧切换网络换 Wi-Fi、插拔网线之后WSL 里的 DNS 配置不更新表现为能 ping 通 IP但域名解析不了二是某些代理类软件在 Windows 侧接管流量之后WSL 里反而完全不通。我的处理方式是改.wslconfig切到镜像网络模式[wsl2] networkingModemirrored dnsTunnelingtrue autoProxytrue memory16GB processors8networkingModemirrored让 Linux 侧直接共享 Windows 的网络接口localhost互通Windows 上监听的端口在 WSL 里能直连反过来也一样。dnsTunnelingtrue把 DNS 查询交给 Windows 处理绕开虚拟网关上那层解析问题。autoProxytrue让它继承 Windows 的代理配置。改完wsl --shutdown重启生效。注意这个模式在较老的 Windows 版本上不支持如果启动失败就退回 NAT 模式改用另一条路在wsl.conf里把generateResolvConf关掉手工写死resolv.conf[network] generateResolvConf false然后写/etc/resolv.conf并把它设为不可变避免被覆盖。这两条路各有取舍镜像模式更省心但依赖系统版本手工写死更稳但换了网络环境要手改。5.2 Docker Desktop 与 WSL2 后端重新挂钩如果你以前用的是 Docker Desktop 的 WSL2 后端导入之后一定会在设置 → 资源 → WSL 集成里发现列表变了新导入的发行版名字可能不在勾选列表里因为集成是按发行版名注册的。处理顺序是先确认 Docker Desktop 本身正常运行然后在 WSL 集成里把新发行版勾上点应用重启。之后在发行版里验证docker context ls docker info | head -20如果报找不到守护进程检查两处一是集成有没有真的勾上有时勾了但没重启 Desktop不生效二是发行版名里有没有空格或大写个别版本对名字格式敏感改个干净的名字反而能解决。还有一个容易忽略的点Docker 的镜像和容器数据存在哪。如果以前是用 Desktop 默认设置数据实际上在 Desktop 自己的磁盘镜像里不在你的发行版里那么这个文件要单独备份。如果是把 Docker 直接装在发行版里不通过 Desktop那所有镜像层都在你的 tar 里导入后docker images直接能看到不用重新拉。我个人在迁移场景里更倾向后者因为所有状态都在一个文件里迁移路径唯一出问题的面最小。5.3 GPU 与本地模型最容易被忽略的那一层这一块和普通开发环境不一样因为它横跨 Windows 驱动和 Linux 用户态两个世界。核心原则只有一条Windows 侧的显卡驱动就是 Linux 侧的驱动不要在 WSL 里再去安装一遍 Linux 版驱动包。导入之后先验证设备节点在不在ls -l /dev/dxg nvidia-smi/dev/dxg这个设备节点是 WSL 的 GPU 直通入口它存在说明 Windows 侧驱动正常工作。nvidia-smi能打出表格说明用户态库路径也挂上了。库文件在/usr/lib/wsl/lib里这个目录由 WSL 在每次启动时注入不属于你的发行版内容所以新机器上要保证 Windows 驱动装好、版本够新。CUDA 工具链的情况要分开看。工具链装在发行版里/usr/local/cuda及其配置会跟着 tar 走但它依赖的驱动接口来自 Windows 侧不跟着走。所以迁移后nvcc --version可能正常实际跑一个 kernel 却报错这种时候去看驱动版本和工具链版本是否匹配。本地大模型这一类负载还有一个体积问题。模型权重目录动辄几十 GB如果它就在发行版里那么导出、传输、导入全程都要为它买单。我的做法是迁移时把模型权重排除在外导入后重新拉取。理由很简单这些文件的来源是公共的重建成本是下载时间而你的环境配置、dotfiles、私有代码是独一无二的重建成本很高。把迁移的带宽花在后一类东西上。模型加载还特别吃内存.wslconfig里的memory和swap要按新机器的实际配置调。从 16G 内存升到 64G 之后还留着旧的memory8GB限制会让你莫名其妙觉得新机器怎么比旧机器还卡。5.4 从 Windows 侧连进来SSH 与端口转发我习惯用 Windows 上的终端工具通过 SSH 连 WSL这样能享受本地终端的分屏、日志回滚和会话管理。导入之后这套连接需要重建。发行版内先装好并启动 SSH 服务sudo systemctl enable --now ssh sudo ss -tlnp | grep sshdNAT 模式下WSL 的 IP 每次启动都可能变直接连不稳定。两种解决方式一是用 Windows 侧做端口转发把本机的某个端口映射到 WSL 的 22 端口二是直接用镜像网络模式这样127.0.0.1就是互通的SSH 客户端连127.0.0.1加端口即可。不管用哪种都要注意两件事。第一件是密钥与 known_hosts导入之后主机指纹变了客户端会报警告并拒绝连接。不要图省事直接关掉校验正确做法是删掉known_hosts里对应那一行再连。第二件是端口冲突Windows 本机的 22 端口如果被其他服务占了映射就会失败换个高位端口比如 2222更稳。sudo sed -i s/^#\?Port .*/Port 2222/ /etc/ssh/sshd_config sudo systemctl restart ssh改端口之后别忘了同步更新 Windows 侧的转发规则和客户端的连接配置。这类改了一半的情况最容易让人以为是服务没起来。6. 返工三次换来的坑清单6.1 vhdx 只涨不缩删了数据空间却没还回来这是 WSL2 最经典的抱怨在 Linux 里删掉 50GB 的构建产物df -h显示空间释放了但 Windows 盘上那个ext4.vhdx还是原来的大小硬盘可用空间一点没变。原因是虚拟磁盘的增长是按需向 Windows 申请但释放回来需要额外动作。三种处理方式按力度排序第一种如果版本支持直接标记为稀疏wsl --manage Ubuntu-22.04 --set-sparse true这个操作之后删除的块可以被 Windows 感知并回收。代价是写入路径多一层某些随机写密集的负载会略慢。我拿它跑日常开发、编译、容器没有明显感觉但如果是数据库一类对延迟敏感的场景我会选择下面第二种。第二种手工压缩wsl --shutdown然后用系统自带的磁盘管理命令行工具附加 vhdx、只读方式压缩、再分离。这个过程需要精确写对文件路径而且要在完全停机状态下做。第三种本质上是导出再导回也是我最后采用的方式wsl --export Ubuntu-22.04 D:\backup\u2204-slim.tar wsl --unregister Ubuntu-22.04 wsl --import Ubuntu-22.04 D:\WSL\Ubuntu-22.04 D:\backup\u2204-slim.tar --version 2因为 tar 只打包真实存在的文件空洞在导出时就被丢掉了导回来就是一个紧凑的 vhdx。缺点是慢且要重新修一遍默认用户。但既然你已经在做迁移这一步顺手就干了等于迁移和瘦身一次完成。我那个 220GB 的 vhdx导出再导入之后变成了 96GB。6.2 跨系统读写慢和权限乱根源在同一个地方/mnt/c下面那套挂载机制是从 Windows 侧读文件性能比在 Linux 原生文件系统上差一个数量级。表现是把项目放在/mnt/d/projects里npm install花的时间是放在~/projects里的几倍文件监听还会时不时失效。这个问题的正确解法不是调参数而是换位置代码放 Linux 侧的 ext4 里需要从 Windows 访问时走\\wsl.localhost\发行版名\home\...这条路。这样 Linux 侧是原生速度Windows 侧的编辑器和资源管理器也能打开。如果在 Windows 侧用编辑器打开 Linux 侧的文件时提示权限问题检查一下/etc/wsl.conf里的metadata有没有开以及挂载选项是不是被改过。挂载选项在运行时也能看到mount | grep -E drvfs|9p输出里如果没有metadata那chmod的结果就不会被持久化表现为重启之后权限又变回去了。这个是我在新机器上折腾最久的一个问题因为症状是有时候行有时候不行非常像玄学。6.3 那些看起来像系统坏了、其实只是配置没跟上的现象迁移之后有几类问题第一次遇到会以为系统损坏实际都是配置层面的现象真实原因处理方式证书校验失败、apt报时间错误系统时钟漂移休眠唤醒后没同步sudo hwclock -s或重启 WSL 实例终端里中文显示成方块或乱码语言环境未生成或终端字体不支持生成对应 locale、设置LANG、换等宽字体.bashrc里的路径全部失效里面写死了旧机器的盘符比如/mnt/d/...变成/mnt/e/...用变量或重新生成避免硬编码盘符命令存在但提示权限不足UID/GID 迁移后错位或用户组权限丢失核对id、groups必要时调整属主启动时报文件系统错误导出时未停机tar 内容不一致从旧盘重新导出一份干净的 tar时钟漂移这条特别值得留意。虚拟机的时钟基准来自宿主长时间休眠之后偏差几小时很正常一旦偏差过大apt更新会因为签名有效期校验失败而报错报错信息完全看不出和时钟有关系。养成习惯导入后第一时间对一下时间。7. 如果重来一次我会怎么设计这套迁移7.1 把环境写成可重建的声明而不是一个巨大的 tar这次迁移让我意识到一个结构性问题我把环境和数据混在一起打包了。结果是 220GB 的包里有几十 GB 的包缓存、一堆随时能重新拉的依赖、以及几 GB 其实不重要的临时文件。更聪明的做法是把环境声明化。具体来说在旧机器上先把这些清单一并导出# 手工安装的包 apt-mark showmanual pkglist.txt # Python 侧 pip freeze requirements.txt conda env export --no-builds -f env.yml 2/dev/null # Node 侧 npm ls -g --depth0 npm-global.txt # 以及在用的 systemd 服务 systemctl list-unit-files --stateenabled services.txt有了这些新环境可以从一个干净的官方根文件系统开始跑一遍脚本重建运行时然后把真正的数据项目代码、证书、密钥、dotfiles、数据库导出文件单独搬过去。这样要搬的体量能小一个数量级而且重建出来的环境更干净没有历史遗留的配置漂移。我现在的做法是导出的 tar 只保留一个精简的基础环境用于应急和快速回滚日常迁移以声明文件为准。两套并存前者保险后者干净。7.2 目录布局和两个脚本把流程固化成肌肉记忆迁移流程走顺之后我把它固化成固定布局和两个脚本。布局上Windows 侧建一个专用根目录所有发行版都放在它下面每个发行版一个子目录另外单独留一个init目录存放那些不随发行版走的东西D:\WSL\ Ubuntu-22.04\ - ext4.vhdx 在这里 Debian\ - 另一个发行版 D:\WSL-Init\ wsl.conf - 导入后放回 /etc/ .wslconfig - 放回 %UserProfile% pkglist.txt requirements.txt README.md - 记录每个发行版的用途和特殊配置脚本上一个负责从旧机器导出并算出校验值一个负责在新机器导入并做基础自检#!/usr/bin/env bash # migrate-export.sh在老环境上跑 set -euo pipefail DISTRO${1:?用法: migrate-export.sh 发行版名 输出目录} OUT${2:?缺少输出目录} wsl.exe --shutdown wsl.exe --export $DISTRO $OUT/$DISTRO-$(date %Y%m%d).tar ls -lh $OUT导入侧的脚本除了导入还会顺手把init目录里的配置放回位置并打印自检清单提醒你逐项确认。这样做的价值不在于自动化本身而在于流程被写成了文件而不是记忆。下次迁移时你不用回想上次那个挂载选项是写在哪个文件里的直接看脚本。这套东西我这次跑了两遍第一遍在老机器上导出第二遍在新机器上导入加修复。事后复盘真正花时间的从来不是导入那十几分钟而是自检和排查那些以为配好了其实没配的细节。所以如果你只从这篇记录里带走一件事我希望是这句把自检清单当成迁移的一部分别把它当成出问题之后的补救动作。我现在每次换环境都是先把wsl -l -v、网络、挂载权限、Docker、GPU 这五项过一遍再开始干活——顺序上花掉的十分钟比事后debug三小时划算得多。