企业官网建设流程全解析

WSL 用久了会发现一个挺有意思的现象：同事来问的问题里，装不上的其实不到三成，剩下七成都卡在「这条操作对应的命令到底叫什么」上。我自己的 WSL 常用命令清单从最初的一张便签，滚到现在按场景分了五大类，每次换机器或者帮人配环境，直接照着敲就行。这份清单主要解决三个事：一是把高频操作压成一行命令，二是把踩过的坑标出来免得重复掉进去，三是让 Windows 和 Linux 两边的文件、网络、工具链能顺畅接上。不管你是刚在 Windows 10 或 Windows 11 上装完 Ubuntu 22.04，还是已经把 WSL2 当主力生产力环境用了半年，下面这些内容应该都能捞到几条能直接用的东西。

1. 先想清楚命令为什么要这样分类

1.1 WSL1 和 WSL2 的差别决定了命令的适用边界

WSL2 底层是一台跑在 Hyper-V 轻量虚拟机里的真 Linux 内核，WSL1 则是把 Linux 系统调用翻译成 Windows 调用。这个差别直接体现在命令行为上：WSL1 里访问/mnt/c和访问本地目录速度差不多，因为压根没有跨虚拟机的文件系统转换；WSL2 里跨/mnt/c读写会走 9P 协议，小文件多的时候慢得明显。

所以我在 WSL2 下有一条硬规矩：任何 git 仓库、node_modules、Python 虚拟环境，一律放在 Linux 侧的~/下面，绝不放在/mnt/c或者/mnt/d的项目目录里。这条规矩不是洁癖，实测跑npm install一个中等规模前端项目，放在/mnt/d下要三四分钟，放在~/projects下四十秒左右，差距就是这么直接。

判断自己当前是哪个版本，用的是这条命令：

wsl --list --verbose # 简写 wsl -l -v

输出的VERSION那一列是 1 还是 2 一目了然。如果某个发行版还是 1，可以原地升级：

wsl --set-version Ubuntu-22.04 2

这个转换过程会花几分钟，取决于发行版里的文件数量，中途别关窗口。转完之后原来的发行版内容都在，只是被搬进了 ext4 虚拟磁盘文件里。

1.2 命令分层的思路：Windows 侧和 Linux 侧别混着记

刚上手最容易混的一点是：wsl开头的命令是 Windows 侧的，得在 PowerShell 或者 CMD 里敲；ls、cd、systemctl这些是 Linux 发行版内部的。很多人习惯在 WSL 终端里敲wsl --shutdown，结果报command not found，就是因为串了层。

我的记忆办法是看「这个操作管的是哪一层」。管发行版整体（安装、卸载、导入、导出、关机）的，走 Windows 侧wsl.exe；管发行版内部（文件、进程、服务、包）的，走 Linux 侧常规命令；管 Windows 和 Linux 之间互通的（路径转换、剪贴板、调用 exe），两边都可以，但通常有更顺手的一边。

按这个思路，我把日常用到的命令分成四大块：安装与初始化、日常启停与状态、文件系统互访、备份迁移与集成。后面每个大块单独讲，命令都配上实际用到的场景和参数解释。

1.3 一份能贴在显示器边上的速查表

先把最常用的十几条列出来，方便直接抄：

这张表不需要背，wsl --help随时能看到全量参数。真正要记住的是思路：要动发行版本身就用wsl前缀，要动里面的东西就正常敲 Linux 命令。

2. 安装与初始化：让 wsl --install 不再卡住

2.1 wsl --install 背后到底做了什么

在较新的 Windows 10 和 Windows 11 上，wsl --install这一条命令其实干了四件事：开启「适用于 Linux 的 Windows 子系统」这个可选功能、开启虚拟机平台功能、下载安装 WSL 内核更新包、从商店拉一个默认发行版（现在是 Ubuntu）。正因为串了这么多步骤，任何一步网络不通都会表现为「卡住不动」。

几个实用参数值得单独拎出来：

# 只装 WSL 本身，不装任何发行版 wsl --install --no-distribution # 指定发行版，并且装完不自动进入 wsl --install -d Ubuntu-22.04 --no-launch # 强制走网络下载内核更新包，而不是等系统组件更新 wsl --install --web-download

--web-download这个参数在不少环境下是救命稻草。系统自带的组件更新通道有时候会长时间没响应，强制走网络下载反而更快更稳。安装完记得重启一次，功能开关生效需要重启系统，这一步省不掉。

2.2 安装速度慢的几种破局方式

wsl --install慢，一般慢在两段：一是内核更新包下载，二是发行版镜像从商店拉取。第一段用--web-download通常能改善；第二段如果迟迟不动，我会直接换思路，走「离线包 + 导入」这条路。

具体做法是：拿到发行版的 tar 包（比如 Ubuntu 22.04 的 rootfs 压缩包），然后用导入命令直接建一个发行版：

# 先建一个空目录作为新发行版的存放位置 mkdir D:\wsl\Ubuntu-22.04 # 从 tar 包导入，目标目录放最后 wsl --import Ubuntu-22.04 D:\wsl\Ubuntu-22.04 D:\downloads\ubuntu-22.04-rootfs.tar --version 2

导入这条路有个副作用必须提前说：导入后的默认用户是root，而不是安装时让你创建的那个普通用户。很多人导入完发现终端提示符变成#，以为是装坏了，其实只是没配用户。

2.3 导入之后必须补的两步配置

第一步是建用户并设密码：

# 在导入的发行版里执行 adduser yourname usermod -aG sudo yourname

第二步是写/etc/wsl.conf，告诉 WSL 默认用哪个用户登录：

# /etc/wsl.conf [user] default=yourname [automount] enabled=true root=/mnt/ options="metadata,umask=22,fmask=11" [interop] enabled=true appendWindowsPath=true

写完保存，回到 PowerShell 执行一次wsl --shutdown，再进来身份就对了。metadata这个选项建议加上，它让 Linux 侧能正确识别文件权限位，否则在/mnt/c下执行chmod +x会毫无反应，脚本没法跑。

appendWindowsPath控制的是 Linux 的PATH里要不要塞进 Windows 的路径。默认是true，好处是能在 WSL 里直接敲code、explorer.exe；坏处是如果 Windows 的PATH特别长，Linux 下which之类命令会变慢。我个人倾向保留true，因为便利性收益更大。

2.4 装完先跑一遍体检命令

新装好的环境我习惯跑这几条确认状态：

# 系统信息 uname -a lsb_release -a # 内核是不是微软定制版 cat /proc/version # 内存和 CPU 是否按配置生效 free -h nproc # 网络是否通 ping -c 3 8.8.8.8

如果free -h显示的内存和你.wslconfig里配的对不上，通常是配置没生效，执行wsl --shutdown完全重启一次即可。.wslconfig这个文件放在 Windows 用户目录下，比如C:\Users\yourname\.wslconfig，格式是这样的：

# C:\Users\yourname\.wslconfig [wsl2] memory=8GB processors=4 swap=4GB localhostForwarding=true

memory给多少合适，取决于你物理内存。16G 的机器给 6 到 8G 比较舒服，32G 的给 12 到 16G。别把物理内存全给出去，Windows 本身还要用。swap给 2 到 4G 就够，跑编译任务时能顶一下内存峰值。

3. 日常高频命令：启停、切换与状态查询

3.1 发行版生命周期命令的完整对照

日常打交道最多的就是这几条，我把它们整理在一起，顺便标注容易记混的地方：

wsl --unregister这条我要多说一句，它不只是「卸载」，而是把整个发行版的虚拟磁盘一起删掉，里面的代码、依赖、数据库全没。真要清理，先导出备份，确认没问题再注销。

3.2 跨系统执行命令的实用场景

wsl后面跟--可以直接在发行版里执行一条命令并返回结果，不进入交互式终端。这个特性在脚本里非常好用：

# 在 Windows 侧查 WSL 里的磁盘占用 wsl -d Ubuntu-22.04 -- df -h # 直接从 Windows 侧跑一个构建 wsl -d Ubuntu-22.04 -- bash -lc "cd ~/projects/app && npm run build" # 把 Windows 上的文件拷进 WSL 再处理 wsl -d Ubuntu-22.04 -- cp /mnt/d/data/input.csv ~/work/

反过来，在 WSL 里调用 Windows 程序也是通的，前提是appendWindowsPath没关：

# 打开资源管理器并定位到当前 Linux 目录 explorer.exe . # 用 Windows 的记事本打开一个文件 notepad.exe ~/notes/todo.txt # 把文本送到 Windows 剪贴板 cat ~/.ssh/id_ed25519.pub | clip.exe

最后那条把公钥塞进剪贴板，是我觉得最省事的一个小技巧。以前总是cat出来选中复制，自从知道clip.exe之后，直接粘贴到网页或者工单系统里就完事。

3.3 状态、日志与版本排查

遇到行为异常，先看状态和版本：

wsl --status wsl --version

wsl --status会告诉你默认发行版、默认版本、内核版本。wsl --version是较新版本才有的，输出更详细，包括 WSLg 版本。如果看到类似「你当前 WSL 版本过旧」的提示，直接更新：

wsl --update wsl --update --web-download

更新完仍然提示版本问题，可以试试回滚到商店版本：

wsl --update --rollback

3.4 关机之后内存为什么不立刻降下来

在任务管理器里会看到一个叫vmmem或者Vmmem WSL的进程占着不少内存。这是因为 WSL2 的虚拟机在后台保留了一段时间。想立刻回收就执行wsl --shutdown，注意这会把所有发行版都关掉，正在跑的编译、服务、数据库连接都会断。

更温和的做法是只关不用的那个发行版：

wsl -t Ubuntu-22.04

我一般的习惯是：切到别的项目之前，把上一个项目的发行版单独终止，既回收内存又不影响其他环境。如果长期占用偏高，可以在.wslconfig里设memory上限，另一个思路是开自动内存回收（较新版本支持）：

[wsl2] memory=8GB autoMemoryReclaim=gradual

这个选项让 WSL 在空闲一段时间后主动把内存还给 Windows，对笔记本续航有实际帮助。

4. 文件系统互访：路径映射是效率的关键

4.1 从 Windows 访问 Linux 文件的两种写法

浏览器地址栏或者资源管理器里输入这两个路径之一：

\\wsl$\Ubuntu-22.04\home\yourname \\wsl.localhost\Ubuntu-22.04\home\yourname

两者的区别在于，\\wsl$是较老的写法，在某些网络环境下会被拦住；\\wsl.localhost是新推荐写法，兼容性更好。如果\\wsl$打不开，换成后一个基本就好了。

顺手可以把常用目录映射成网络驱动器，之后在 VS Code 里打开更方便：

net use Z: \\wsl.localhost\Ubuntu-22.04\home\yourname

需要删掉映射就用net use Z: /delete。

4.2 从 Linux 访问 Windows 文件与 wslpath 的妙用

Windows 的盘符在 WSL 里挂在/mnt下面，C 盘是/mnt/c，D 盘是/mnt/d，以此类推。手动拼路径容易出错，特别是遇到反斜杠和空格，这时候wslpath就派上用场了：

# Windows 路径转 Linux 路径 wslpath -u 'D:\code\my project' # 输出：/mnt/d/code/my project # Linux 路径转 Windows 路径 wslpath -w ~/projects/app # 输出：\\wsl.localhost\Ubuntu-22.04\home\yourname\projects\app # 直接拿到 Windows 风格的绝对路径，便于贴到其他程序里 wslpath -w -a ./dist

-a参数是把相对路径转成绝对路径。这个小功能在写脚本时特别有用，比如要把构建产物交给一个 Windows 程序处理，路径格式不对就会报错，用wslpath转一下基本不会出问题。

4.3 项目目录该放哪：一条经验换来的性能差距

前面提过一次，这里展开说。WSL2 访问/mnt/*走的是网络文件协议，元数据操作（stat、open、close）开销很大。前端项目node_modules动辄几万个文件，放在/mnt/d下，npm install和热更新都会明显变慢。

我的做法是在 Linux 侧建一个统一的工作目录：

mkdir -p ~/work

然后 Windows 侧通过\\wsl.localhost\Ubuntu-22.04\home\yourname\work访问，需要拖文件的时候直接开这个路径。反过来，如果有些数据必须留在 Windows 盘，就只放源数据，处理完的中间产物写到 Linux 侧。

注意：把 git 仓库放在/mnt/c下还有一个隐性坑，行尾符和文件权限经常被 Windows 侧程序改来改去。git status动不动就显示一堆修改，实际上是权限位变动。把仓库移到 Linux 侧能根治这类问题。

4.4 文件传输的几种命令组合

小文件直接cp：

cp /mnt/d/data/config.json ~/work/

大目录用rsync更可靠，能续传也能看进度：

rsync -avh --progress /mnt/d/dataset/ ~/work/dataset/

从 Linux 往外拷也一样，方向反过来即可。如果数据量大且只做一次性迁移，先在 Windows 侧把目录压缩成 tar，再在 WSL 里解压，速度会快不少：

tar -xf /mnt/d/archive/data.tar.gz -C ~/work/

原因还是那一条：小文件的跨系统读写代价高，打包成一个文件之后，跨系统只走一次大文件传输，效率天差地别。

5. 备份、迁移与磁盘空间管理

5.1 导出与导入：换机器最稳的方案

wsl --export会把整个发行版打包成一个 tar 文件，包含系统、用户目录、已装的软件。换电脑时，把 tar 拷过去导入，环境几乎原样恢复：

# 导出，路径自己定 wsl --export Ubuntu-22.04 D:\backup\ubuntu-2204-20250101.tar # 想压缩体积可以加 --vhd，导出成 vhdx 格式 wsl --export Ubuntu-22.04 D:\backup\ubuntu-2204.vhdx --vhd

导出时间取决于发行版大小，几十 G 的话喝杯咖啡的功夫。导入前先确认目标目录所在磁盘有足够空间，导入是解包展开，占用的空间和导出文件大小不是一回事。

导入命令前面提过，这里补两个细节。一是导入时如果同名发行版已存在，会直接报错，得先注销或者改个名字；二是导入后的发行版默认挂在root下，记得按 2.3 节的步骤配/etc/wsl.conf。

5.2 迁移到非系统盘的完整步骤

C 盘空间紧张是 WSL 用户的常见困扰，把 ext4 虚拟磁盘搬到 D 盘是标准解法。我用得最顺的流程是「导出 + 导入 + 注销」，全程不用碰底层的 vhdx 文件：

# 1. 先关掉所有 WSL wsl --shutdown # 2. 导出到目标盘 wsl --export Ubuntu-22.04 D:\wsl\ubuntu-backup.tar # 3. 注销原发行版 wsl --unregister Ubuntu-22.04 # 4. 在新的位置导入 mkdir D:\wsl\Ubuntu-22.04 wsl --import Ubuntu-22.04 D:\wsl\Ubuntu-22.04 D:\wsl\ubuntu-backup.tar --version 2 # 5. 恢复默认用户配置后重启 wsl --shutdown

第 5 步别忘了，注销再导入之后/etc/wsl.conf里的默认用户配置还在（因为它在系统里），所以通常不需要重新写。但如果导入的是别人给的 tar 包，那就得自己配。

5.3 虚拟磁盘瘦身：删了文件为什么空间没回来

WSL2 的磁盘是一个只增不减的 vhdx 文件。你在里面删了 20G 的东西，Windows 侧的 vhdx 文件大小纹丝不动。这不是 bug，是虚拟磁盘的设计。

较新版本的 WSL 支持稀疏磁盘，可以自动回收：

wsl --manage Ubuntu-22.04 --set-sparse true

如果没有这个参数，就手动压缩：

# 关闭 WSL wsl --shutdown # 打开 diskpart diskpart

进入交互后依次执行：

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

compact vdisk这步的时间取决于磁盘大小和碎片程度，几十 G 的话可能要十几分钟。压缩前建议先导出备份，虽然这个操作本身风险不高，但涉及底层磁盘文件，留个后路总是好的。

5.4 注销和卸载的区别值得说清楚

wsl --unregister注销的是发行版，虚拟磁盘文件会一并删除。而「卸载 WSL」在 Windows 的「启用或关闭 Windows 功能」里关掉那个可选功能，是把整个子系统关掉，所有发行版的注册信息还在，重新开启功能后能继续用。

如果你只是想让某个发行版不再出现在wsl -l列表里，用--unregister；如果是彻底不用 WSL 了，先备份再用系统功能关闭。顺序弄反了会比较麻烦。

6. 图形界面、GPU 与容器集成命令

6.1 图形程序能直接跑，靠的是 WSLg

Windows 11 以及较新的 Windows 10 上，WSL 内置了 WSLg，图形程序开箱可用。验证方法很简单：

# 装一个小工具试试 sudo apt update && sudo apt install -y x11-apps xeyes

如果弹出一个小眼睛窗口，说明图形链路通了。环境变量里DISPLAY一般不需要手动设，WSLg 会自己注入。

这个能力带来的便利是：一些只有图形界面的工具（比如某些调试器、数据库客户端、图像处理软件）可以直接装在 WSL 里跑，不用在 Windows 上再装一份，环境更统一。

6.2 GPU 直通的检查命令

想在 WSL 里做深度学习，前提是 Windows 侧装好显卡驱动（注意是 Windows 版驱动，不要在 WSL 里装 Linux 显示驱动）。装完后，WSL 里应该能直接用：

nvidia-smi

这条命令能输出显卡型号、驱动版本、显存占用，说明直通正常。如果提示找不到命令，先确认驱动装没装，再确认 WSL 是不是最新：

wsl --update

路径上有个细节：WSL 会把宿主机的驱动库挂到/usr/lib/wsl/lib，这个目录通常已经加进动态链接库搜索路径了。手动检查可以看：

ls /usr/lib/wsl/lib echo $LD_LIBRARY_PATH

接下来装 CUDA 工具链，选 WSL 专用的版本就行。装完用nvcc --version验证。跑训练之前建议先用一个小张量试一下，确认能正常调用显卡，避免跑了几小时才发现一直在用 CPU。

6.3 Docker 集成的排查思路

很多人是在 WSL 里用 Docker Desktop 的 WSL 后端，报错最典型的一种是启动时提示连不上远程计算机或者引擎起不来。排查顺序我一般这么走：

先在 PowerShell 里确认 WSL 本身正常：

wsl -l -v wsl --status

如果列表能正常输出、发行版状态正常，那问题多半在 Docker Desktop 那边。可以做的事包括：确认 Docker Desktop 的设置里「使用基于 WSL 2 的引擎」已勾选，并把要用的发行版加进集成列表；然后完全退出 Docker Desktop 再重开；还不行就重置一下 Docker 的 WSL 数据。

如果反过来，想在发行版里直接用docker命令而不经过桌面版，也可以装发行版原生的 Docker 引擎，用systemctl管理，前提是发行版启用了 systemd。

6.4 systemd 的启用与常用服务命令

新版本 WSL 支持 systemd。在/etc/wsl.conf里加一行：

[boot] systemd=true

然后在 PowerShell 执行wsl --shutdown，重新进入后：

systemctl status

能正常输出就说明 systemd 起来了。之后systemctl start/stop/enable这些常规操作都能用，装 MySQL、Redis、Nginx 之类的服务就顺理成章了。

统一把服务装进 WSL 之后，开机不用等它们启动，需要时wsl进来systemctl start一下，用完wsl --shutdown一起关掉，这种按需启动的方式对笔记本很友好。

7. 开发环境联调与终端体验

7.1 VS Code 接 WSL 的正确姿势

在 WSL 的项目目录下敲：

code .

VS Code 会以远程模式打开当前目录，终端、调试器、扩展都在 Linux 侧运行，文件读写走的是 Linux 文件系统，前面说的性能问题自然就绕开了。第一次用需要装 Remote 开发相关的扩展，装完一次就行。

如果code命令不存在，通常是appendWindowsPath被关了，或者 VS Code 装在非默认位置。可以手动在 Linux 的~/.bashrc里加个别名指向code的命令行脚本，路径一般在/mnt/c/Users/你的用户名/AppData/Local/Programs/Microsoft VS Code/bin/code。

Windows 侧的 VS Code 窗口和 WSL 侧的远程窗口是两个概念，看到窗口标题里写着远程主机名，就说明连对了。

7.2 终端字体与显示效果的调优

想让 WSL 终端接近 macOS 那种清爽感，主要调三处：字体、行高、配色。

字体选等宽且带编程连字的，比如 Cascadia Code、JetBrains Mono、Fira Code，Windows Terminal 的settings.json里对应字段是：

"profiles": { "defaults": { "font": { "face": "JetBrains Mono", "size": 11, "weight": "normal" }, "opacity": 95, "padding": "8, 8, 8, 8" } }

face换字体，size控制字号，opacity做轻微透明能让层次更舒服，padding是留白。行距在 Windows Terminal 里没有直接参数，靠字体和字号搭配来调。

配色方面，主题里选一个低饱和的配色方案，长时间看眼睛不容易累。另外建议把光标形状设成竖线并且开启闪烁，配cursorShape字段即可。

7.3 WSL 里必备的 Linux 命令清单

既然 WSL 里跑的是真 Linux，常规命令就是基本功。我按使用频率列一批，都是日常绕不开的：

文件与目录

ls -alh # 带权限、大小、隐藏文件 cd - # 回到上一个目录 du -sh * # 看每个子目录占用 find . -name "*.log" -size +100M # 找大日志 tree -L 2 # 两层的目录树

文本处理

grep -rn "TODO" . --include="*.py" sed -i 's/old/new/g' config.ini awk -F',' '{print $1, $3}' data.csv | head sort -k2 -nr access.log | head -20

进程与网络

ps aux | grep node top -o %MEM kill -9 <pid> ss -tulnp # 看监听端口，比 netstat 更快 curl -I https://example.com

打包与传输

tar -czvf archive.tar.gz ./dir tar -xzvf archive.tar.gz -C /tmp rsync -avh --progress src/ user@host:/dst/

这些命令在 WSL 里的行为和标准 Linux 完全一致，学一次通用。真正需要额外注意的是路径：涉及/mnt的操作都会慢一些，能用 Linux 侧路径就别用跨系统路径。

7.4 和 git、docker、k8s 等工具的衔接

git装在 Linux 侧，配置一次全局信息：

git config --global user.name "yourname" git config --global user.email "you@example.com" git config --global core.autocrlf input

core.autocrlf input这行值得单独配，能避免行尾符被反复改写。如果要在 WSL 里用 Windows 侧的凭据，可以配合credential.helper指向 Windows 的凭据管理器，省去重复输入。

kubectl和docker都是命令行工具，装在 Linux 侧体验最好，配置文件和上下文都存在~/.kube和~/.docker下，跟着发行版一起走，换机器导出导入就完事。

8. 常见问题排查速查表

8.1 报错清单与逐条处理

8.2 网络与 DNS 类问题的排查顺序

WSL2 的网络是 NAT 模式，Linux 侧有一套自己的 DNS 配置。遇到解析异常，先看/etc/resolv.conf：

cat /etc/resolv.conf

默认情况下这个文件由 WSL 自动生成，会指向虚拟网关。如果发现解析经常失败，可以关掉自动生成，改为手动配：

# /etc/wsl.conf [network] generateResolvConf=false

然后在/etc/resolv.conf里写自己需要的 DNS 地址，并把文件设为不可变，防止被覆盖：

sudo chattr +i /etc/resolv.conf

较新版本的 WSL 支持镜像网络模式，在.wslconfig里配networkingMode=mirrored，让 Linux 侧和 Windows 侧共享网络栈，localhost转发和局域网访问都会更顺。这个模式对 Windows 版本有要求，太旧的版本不支持，配了不生效就先升级。

服务端口映射也是常见需求。默认情况下，Linux 侧监听的端口 Windows 侧可以通过localhost访问，如果访问不到，先确认服务是监听在0.0.0.0还是127.0.0.1。监听在127.0.0.1时，某些转发场景会失败，改成0.0.0.0通常能解决。

8.3 权限与性能类问题的处理心得

权限问题很大一部分来自/mnt下的挂载选项。除了前面说的metadata，umask和fmask也会影响文件权限表现。默认配置下所有文件看起来都是 777，实际上 Windows 侧并没有这个概念，所以别指望在这上面调权限。

Linux 侧的文件就正常了，chmod、chown都按标准行为走。所以我一直建议：需要控制权限的东西放 Linux 侧，需要和 Windows 程序共享的东西放/mnt，两边各司其职。

性能方面有几条实测有效的做法。一是把经常编译的项目放 Linux 侧；二是关掉不必要的 Windows 路径注入（如果appendWindowsPath造成which卡顿）；三是给.wslconfig里的内存和 CPU 设一个合理上限，别让它把整机资源吃满；四是定期清理 vhdx 的空洞，磁盘 IO 会明显变好。

8.4 我自己踩过的几个坑

第一个坑是导出时没关 WSL。导出过程中如果发行版还在运行，tar 包有可能不完整，导入后出现奇怪的损坏。后来我养成了固定动作：导出前先wsl --shutdown。

第二个坑是在/mnt/c下直接git clone。前面说过性能问题，实际遇到过更麻烦的情形：Windows 侧的安全软件扫描目录时锁住文件，导致 git 操作随机报错，排查了半天才发现原因。换到 Linux 侧之后再没出现过。

第三个坑是忘记配置默认用户，导入的发行版一直用 root 写文件，结果~/.ssh之类目录的属主全变成 root，普通用户下无法读取。修复办法是回到 root 身份把属主改回来：

chown -R yourname:yourname /home/yourname

第四个坑是磁盘空间。有次编译产生了几十 G 的中间产物，删完之后 C 盘空间没回来，一度以为系统出问题。了解 vhdx 只增不减之后，做了压缩操作，空间立刻回来。从那次起，我把 WSL 的磁盘目录放在数据盘，并且在.wslconfig里限制了内存，避免再出现这种情况。

真要把这套东西用顺，我的体会是：把命令分成「管发行版」和「管发行版内部」两类来记，把文件分成「Linux 侧」和「Windows 侧」两类来放，剩下的就都是熟练度问题。上面这些命令不需要一次全记住，遇到具体场景回来翻对应那一节就行。