WSL Ubuntu 换 apt 国内镜像源：从龟速到秒装，一文搞定

装完 WSL 之后第一件事做什么？我的答案永远是：先把 apt 换到国内镜像源，再谈别的。这句话我反复说过很多次，每次帮朋友排查新装的 WSL 卡顿，十个里有八个都栽在同一件事上——打开终端敲下 sudo apt update，进度条以几十 KB/s 的速度龟速爬行，等了几分钟最后还给你一个超时错误。这时候你装的就不是 Linux 开发环境，而是耐心。

WSL（Windows Subsystem for Linux）是微软提供的官方 Linux 运行环境，让开发者能直接在 Windows 里使用 Ubuntu 的命令行工具、编译器和各种开源软件；apt 是 Ubuntu 官方的包管理器，几乎所有软件都靠它来安装和更新；镜像源则是各大高校和云厂商维护的官方软件源同步副本。把这三样串起来，就是今天要聊的核心：怎么在 WSL 的 Ubuntu 里，把 apt 默认访问的海外源换成国内镜像源，让安装软件的速度从"刷完一集剧还没好"变成"倒杯水回来就装完了"。

这篇内容适合这几类人：刚接触 WSL、正卡在慢速安装上的新手；想搞明白 sources.list 和 ubuntu.sources 这两个文件到底怎么回事的进阶用户；以及换源之后遇到各种报错、想一次性把坑填平的开发者。我会把原理、实操、排错都讲清楚，你照着抄就行。

1. 先搞清楚：到底为什么要给 WSL 换 apt 源

1.1 WSL 本身的定位：它就是一台没有显示器的 Linux

很多人第一次听到 WSL 会有点懵，它到底是个虚拟机还是模拟器？准确说，WSL2 是微软基于 Hyper-V 虚拟化技术实现的一个轻量级 Linux 运行环境，但它和传统虚拟机的体验完全不同。你不需要安装完整的虚拟机管理软件，也不用分配内存和磁盘，只需要在 Windows 里执行一条 wsl --install，它就会自动拉取 Ubuntu 发行版镜像并完成初始化。

它最吸引人的地方在于和 Windows 的深度融合。你用 VS Code 打开一个 WSL 内的项目，编辑器会自动以远程模式连接进去，终端、调试器、扩展全都工作在 Linux 环境里；你在 Windows 资源管理器里可以直接访问 WSL 内部文件，也可以反过来在 Linux 里访问 Windows 的磁盘目录。对于需要运行 Linux 工具链、编译 C/C++ 项目、跑 ROS、调用 GPU 做深度学习的人来说，WSL2 基本就是零成本解决了"开发环境不统一"的痛苦。

但环境再好，软件装不上就等于零。WSL 里的 Ubuntu 是一个完整的系统，它装软件的核心通道就是 apt，而 apt 默认连接的软件仓库服务器在海外。这个问题从 WSL 诞生的那天起就存在，一直坑到今天的 2025 年也没变。

1.2 慢的问题根源：Ubuntu 官方源在海外

apt 工作原理不复杂，你可以把它理解成一个"谷歌搜索+应用商店"的合体。当你执行 sudo apt update 时，apt 会读取源配置文件，去里面列出的服务器地址下载一份软件包索引；当你执行 sudo apt install 软件名 时，它再从这些服务器下载对应的 .deb 安装包。源配置文件里写的是什么地址，它就访问什么地址。

Ubuntu 系统的默认源地址只有两个：

• http://archive.ubuntu.com/ubuntu，负责主要的软件包和更新；
• http://security.ubuntu.com/ubuntu，负责安全补丁。

这两个服务器都部署在海外。国内家庭宽带、教育网、企业网络访问跨国服务器的物理距离远，经过的骨干网节点多，高峰期经常出现连接不稳定、带宽跑不满的情况。加上 apt 对连接失败的重试机制本身比较保守，一旦某个文件下载超时，整个安装流程就会卡住或者中断，非常折磨人。

换源要解决的就是这个问题：把配置文件里的官方地址替换成国内镜像站地址，这些镜像站每隔几小时到一天就会同步一次 Ubuntu 官方仓库的所有内容，数据是一致的，只是访问路径变近了，下载速度自然就上来了。

1.3 换源不等于改系统，放心搞

我见过不少新手对"改源"这件事有心理负担，觉得动系统配置文件很危险。其实完全不用慌。apt 源配置就是一个纯文本文件，你改的是"软件从哪里下载"这个地址，不涉及内核、驱动程序、系统核心组件。想恢复原状，把备份文件覆盖回去，或者把地址改回 archive.ubuntu.com 即可，整个过程 30 秒内就能完成回滚。

真正要记住的唯一原则是：修改之后必须执行一次 sudo apt update 刷新索引，让 apt 去新的服务器地址获取软件包列表。如果不做这一步，apt 用的还是旧索引，虽然也能装软件，但可能装到一半发现文件找不到，反而制造新的报错。把这个习惯刻在脑子里，换源这件事就成功了一半。

2. 动手前花三分钟做的准备工作

2.1 确认 Ubuntu 版本和源文件格式

不同版本的 Ubuntu，apt 源配置文件的位置和格式差别很大。很多教程只讲老格式，照着改新版系统就会翻车，所以第一步一定是先确认你的系统版本。

在 WSL 终端里执行：

bash复制cat /etc/os-release
lsb_release -a

看输出里的版本号。这里要记住一个关键分界线：Ubuntu 24.04 是一个格式切换的里程碑版本。24.04 及之后的版本，apt 源默认使用 deb822 格式，配置文件在 /etc/apt/sources.list.d/ubuntu.sources；而 24.04 之前的版本，比如 20.04、22.04，使用的是传统 one-line 格式，配置文件是 /etc/apt/sources.list。

区分方法也很简单，直接看文件：

bash复制cat /etc/apt/sources.list

如果文件内容是一行行以 deb 开头的地址，就是老格式；如果提示文件不存在或者内容为空，再检查一下 /etc/apt/sources.list.d/ 目录下有没有 ubuntu.sources 文件。两种情况的操作我都放在后面第 4 节，按自己的版本对号入座即可。

2.2 不管怎么改，先把源文件备份了

这是我在所有环境实操时都坚持的习惯，也是给你上的第一道保险。备份命令很简单：

bash复制# 老版本 Ubuntu（20.04/22.04）
sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak.$(date +%F)

# 新版本 Ubuntu（24.04+）
sudo cp /etc/apt/sources.list.d/ubuntu.sources /etc/apt/sources.list.d/ubuntu.sources.bak.$(date +%F)

$(date +%F) 会自动拼上当天日期，比如 sources.list.bak.2025-06-10，这样即使你多次换源也不会覆盖之前的备份。之后万一新源配置出了问题，一条命令就能完整恢复：

bash复制sudo cp /etc/apt/sources.list.bak.2025-06-10 /etc/apt/sources.list

备份的本质不是怕改坏，而是为了"可以随时后悔"。我早期换源的时候曾经手滑把一行地址的路径写错了，折腾了半小时才定位问题，要是当时有备份，三秒钟就能回到原点。这个习惯成本极低，收益极高。

2.3 实际测一下现在的下载速度

换源前建议先直观感受一下当前速度，这样换完之后你才能确认"到底是真变快了，还是我自己自我安慰"。最直接的办法是给一次 apt update 计时：

bash复制time sudo apt update

看输出的 real 时间。如果默认源执行一次 update 要两三分钟甚至更久，那说明慢的问题确实存在。换源后再执行一次同样的命令，对比时间差，效果一目了然。

如果想更精确地测下载带宽，可以下载一个小包看实时速度：

bash复制sudo apt install -y --download-only tree

执行后注意观察 Get 那一行的下载速度显示。apt 会打印出每秒下载的字节数，比如几百 KB/s 和几 MB/s 的差距非常直观。测完如果不想安装，用 sudo apt clean 清掉下载缓存即可。

3. 镜像源怎么选：主流镜像站横向对比

3.1 几个靠谱的 Ubuntu 镜像源

国内可用的 Ubuntu 镜像站数量不少，但质量参差不齐。我不会把所有站都列一遍，只讲几个我自己用过的、同步比较及时、带宽相对稳定的：

所有镜像站的 Ubuntu 仓库路径都是统一的，在域名后加 /ubuntu/ 即可。比如完整的软件源地址就是 https://mirrors.aliyun.com/ubuntu/，后面会拼接 dists、pool 这些标准目录结构。

经历过几轮大版本更新之后，我个人的实测感受是：清华和阿里是综合表现最稳的两个。如果非要二选一，家里用阿里，校园网用清华，基本不会踩坑。

3.2 选源的核心标准：同步频率、网络链路、协议支持

选镜像源看起来是随便挑一个就行，其实背后有三个硬指标值得关注。

第一个是同步频率。镜像站不是实时和官方仓库完全一致的，而是定期同步。主流镜像站一般几小时同步一次，足够日常使用；但如果你刚发布完一个 Ubuntu 新版本，急切想用新版本的软件包，就要挑同步最快的那家，否则可能出现"我已经换了新版本源，但镜像站还没同步完"的情况。

第二个是网络链路。这一点最直接地影响速度。你所在的网络环境决定了哪家镜像对你最友好：校园网用户用清华、北外这类高校镜像通常延迟极低；家庭宽带用户用阿里云、华为云这种有商业带宽保障的镜像更稳；云服务器用户直接选同厂商的镜像站，内网链路几乎是无损的。

第三个是 HTTPS 支持。现在的镜像站基本都支持 HTTPS 访问，在源地址里直接写 https:// 前缀即可。这样即使在不可信的局域网环境里，软件包下载也不容易被中间人篡改。唯一需要注意的是，某些镜像站的 HTTPS 证书偶尔会有过期问题，碰到"Certificate verification failed"报错时，要么换一个镜像站，要么临时改用 HTTP 地址应急。

3.3 为什么我不建议所有场景都无脑用同一个源

很多人图省事，喜欢把所有软件源都配成同一个镜像站，apt 用清华，pip 用清华，npm 也用清华。这个做法在大部分时候没问题，但不一定是最优解。

不同镜像站对不同生态的同步策略不一样。比如有的站 apt 源同步得飞快，但 PyPI 的同步间隔偏长；有的站 pip 源很全，但 Docker 镜像加速不稳定。我的建议是：apt 源选一个最稳的固定下来，其他生态单独看各家镜像站的公告再决定。别为了统一而统一，最终目标只是下载快、不报错。

另外提醒一点，换源之后不要去动镜像站的 HTTPS 证书校验逻辑，更不要去"关闭验证"来绕错误。遇到证书问题优先换源或者检查系统时间，系统时间不对导致的证书校验失败是新手很容易忽略的坑。

4. 详细实操：两种格式的源文件分别怎么改

4.1 老版本 Ubuntu（20.04/22.04）：改 /etc/apt/sources.list

先看传统 one-line 格式长什么样。以 Ubuntu 22.04 为例，默认的 /etc/apt/sources.list 大致是：

code复制deb http://archive.ubuntu.com/ubuntu jammy main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu jammy-updates main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu jammy-backports main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu jammy-security main restricted universe multiverse

每行拆开看其实信息量很大：

• deb：表示这是二进制软件包仓库，如果是 deb-src 则是源码包仓库，日常不需要；
• http://archive.ubuntu.com/ubuntu：仓库地址；
• jammy：发行版代号，22.04 是 jammy，20.04 是 focal；
• main restricted universe multiverse：组件分类，分别代表官方支持、受限软件、社区自由软件、非自由软件，全选就行。

替换成阿里云源，最稳的做法是先用 sed 批量替换，不手工逐行改，避免遗漏：

bash复制sudo sed -i 's@http://archive.ubuntu.com/ubuntu@https://mirrors.aliyun.com/ubuntu@g' /etc/apt/sources.list
sudo sed -i 's@http://security.ubuntu.com/ubuntu@https://mirrors.aliyun.com/ubuntu@g' /etc/apt/sources.list

这里我用的分隔符是 @ 而不是常见的 /，是因为源地址本身就带斜杠，用 @ 可以省去一堆转义。替换完成后查看文件确认效果：

bash复制cat /etc/apt/sources.list

如果地址里的域名已经变成 mirrors.aliyun.com，那配置就完成了。想用清华源就把命令里的 mirrors.aliyun.com 换成 mirrors.tuna.tsinghua.edu.cn，其他镜像站同理。

4.2 新版本 Ubuntu（24.04+）：改 /etc/apt/sources.list.d/ubuntu.sources

24.04 开始，Ubuntu 切换到了 deb822 格式，配置文件结构变了。默认的 ubuntu.sources 内容大概是：

code复制Types: deb
URIs: http://archive.ubuntu.com/ubuntu/
Suites: noble noble-updates noble-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Types: deb
URIs: http://security.ubuntu.com/ubuntu/
Suites: noble-security
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

这个格式本质上和 one-line 表达的是同样的信息，只是分成了字段。URIs 是仓库地址，Suites 是发行版代号和更新类别，Components 是组件，Signed-By 指向密钥文件用于校验。

替换地址同样用 sed：

bash复制sudo sed -i 's@http://archive.ubuntu.com/ubuntu@https://mirrors.tuna.tsinghua.edu.cn/ubuntu@g; s@http://security.ubuntu.com/ubuntu@https://mirrors.tuna.tsinghua.edu.cn/ubuntu@g' /etc/apt/sources.list.d/ubuntu.sources

注意这里我把 security 段也一并替换了。原因是绝大多数国内镜像站都会同步 Ubuntu 的 security 仓库，指向镜像站完全没有问题。你不需要刻意保留原来的 security.ubuntu.com 地址，那样反而会让安全更新走慢速链路。

改完之后检查一下：

bash复制cat /etc/apt/sources.list.d/ubuntu.sources

确认两个 URIs 字段都指向镜像站即可。Ubuntu 25.04 及后续版本大概率继续沿用这个格式，学会这一节能管好几年。

4.3 用 sed 批量替换时的必要检查和避坑

sed 批量替换很方便，但有两个坑必须注意。

第一个坑是"替换后源地址多了一层路径"。有些教程给的 sed 命令会把 archive.ubuntu.com/ubuntu 替换成 mirrors.xxx.com/ubuntu/ubuntu，多出一个重复的 /ubuntu。原因是他们把匹配地址写成了仅包含 archive.ubuntu.com，而源文件里原本就带着 /ubuntu 路径。我给你的命令里匹配的是完整路径，不会出现这个问题。

第二个坑是"只改了 http 没改 https"。默认源地址是 http:// 开头，替换命令里如果没处理协议部分，最终地址可能变成 https://archive.ubuntu.com 这种半吊子状态。所以我建议用我写的完整命令，把域名连同协议一起匹配。

改完文件之后，先不急着装软件，执行一遍刷新索引：

bash复制sudo apt update

观察输出里每一行前的状态：

• Hit：索引没有变化，服务器直接确认了，非常快；
• Get：正在下载新的索引文件，后面的速度显示就是镜像站的真实速度；
• Err：出现问题，需要进入第 5 节排查。

4.4 改完之后怎么验证效果

apt update 刷完索引之后，再验证一下软件包的下载和安装是否正常。测试包我习惯用轻量级的，省时间：

bash复制time sudo apt install -y tree

如果看到下载速度达到几 MB/s，安装在几秒内完成，说明换源成功了。time 输出的 real 时间可以作为你以后判断 apt 是否恢复正常节奏的参考基线。

另外一个细节点：如果你用的是 WSL2，apt 的下载速度还受 Windows 侧网络环境影响。镜像站跑满带宽之后，WSL 里的下载速度通常会很快；如果仍然只有几百 KB/s，问题不一定在源上，需要检查网络栈，这就是第 5 节要聊的内容了。

5. 换源后最常见的坑和排查记录

5.1 apt update 报 "Failed to fetch" 怎么办

这是换源后出现频率最高的报错，完整信息通常是：

code复制Err:1 https://mirrors.xxx.com/ubuntu/dists/noble/InRelease
  Connection failed [IP: ...]

遇到这个报错，先不要慌，按照下面的顺序排查：

一个一个说。最轻微的情况是临时网络抖动，直接重试一次可能就好了：

bash复制sudo apt update -o Acquire::Retries=3

Acquire::Retries 是 apt 自带的连接重试参数，默认重试次数很少，网络一抖就容易失败。加上这个参数后遇到偶发性超时，apt 会自动多试几次，很多问题就这么糊弄过去了。这个方法同样适用于安装大软件包时中途断线的情况。

如果重试多次仍然报错，把报错里的镜像站地址记下来，换一个镜像站。我在 3.1 里列的那几个主流站，至少有一个在你当前网络下是通的，真的遇到多家全挂的概率极低。

5.2 "The repository does not have a Release file" 是什么情况

另一个常见报错长这样：

code复制E: The repository 'https://mirrors.xxx.com/ubuntu noble Release' does not have a Release file.

翻译一下：apt 去了你配置的地址找发行版元数据文件 Release，但没找到。原因通常有三个：

一是发行版代号写错了。比如你是 Ubuntu 22.04，代号是 jammy，但你写成了 noble（那是 24.04 的代号），镜像站上当然没有对应目录。检查一下 /etc/os-release 里的 VERSION_CODENAME，确保源文件里的代号和系统版本一致。

二是镜像站刚同步新版本，目录还不完整。这种通常出现在 Ubuntu 大版本发布后的头一两天，清华、阿里这类主力站一般几小时内就能同步好，要么等等，要么换个已经同步完的站。

三是源文件路径配错了。一个很实用的检查方法是手动访问一下 Release 文件，看服务器上到底有没有：

bash复制curl -I https://mirrors.aliyun.com/ubuntu/dists/jammy/Release

如果返回 200 OK，说明路径没问题；如果返回 404 Not Found，问题就出在发行版代号或镜像站同步上。这一步能帮你快速把排查范围缩小一大半。

5.3 为什么我换了源还是慢：DNS 和 IPv6 的坑

换源之后还是慢，这是最让人上火的场景。先别急着质疑镜像站，问题大概率出在 WSL 自身的网络协议栈上。

WSL2 默认的网络机制是 NAT 模式，Windows 宿主机负责网络地址转换和 DNS 转发。WSL 里的 /etc/resolv.conf 通常是自动生成的，指向一个虚拟 DNS 地址。在某些网络环境下，这个虚拟 DNS 解析很慢，甚至解析失败，结果就是 apt 连接镜像站之前卡在域名解析环节，看起来慢得离谱。

你可以先用这条命令测一下域名解析耗时：

bash复制time getent hosts mirrors.aliyun.com

如果这条命令耗时超过几百毫秒，甚至超时，那就是 DNS 的问题。一个立竿见影的缓解方法是让 apt 强制走 IPv4：

bash复制echo 'Acquire::ForceIPv4 "true";' | sudo tee /etc/apt/apt.conf.d/99force-ipv4

这个操作背后的逻辑是：不少家庭路由器和特殊网络环境的 IPv6 支持有 bug，导致系统优先走 IPv6 时连接不稳定，强制走 IPv4 就绕开了这个坑。执行完重新 apt update，通常速度会有明显改善。这个方法我实测过很多次，属于 WSL 换源后的"隐藏必做项"，建议直接配上。

另外，如果你用的是 Windows 11 较新版本，还可以在用户目录下创建 .wslconfig 文件，把 WSL2 的网络模式改成镜像模式：

code复制[wsl2]
networkingMode=mirrored

改完后在 PowerShell 里执行 wsl --shutdown 重启 WSL。镜像模式下 WSL 直接共享 Windows 的网络栈，DNS 行为更接近宿主机，某些网络环境下的连接稳定性会好很多。不过这个属于进阶优化，如果当前 NAT 模式用着没问题，可以不改，免得引入新的变量。

5.4 想回滚到官方源怎么操作

换完源之后如果用了几天觉得不习惯，或者某个镜像站同步出了问题，想回官方源完全没问题。之前备份的文件就是干这个用的：

bash复制# 老版本
sudo cp /etc/apt/sources.list.bak.2025-06-10 /etc/apt/sources.list

# 新版本
sudo cp /etc/apt/sources.list.d/ubuntu.sources.bak.2025-06-10 /etc/apt/sources.list.d/ubuntu.sources

然后照例 sudo apt update 刷新索引。日常体验会回到默认状态，慢是慢一点，但能用。如果你没备份，也可以用 sed 把域名替换回去，方法就是把 4.1 里 sed 命令的替换源和替换目标对调。

5.5 顺带排查：WSL 本身升级慢的问题

下面这个问题和 apt 本身无关，但因为和高频搜索词一起出现，这里多说一句。刚装完 WSL 或者手动执行 wsl --update 时，有些人会遇到下载极慢、一直卡在进度条的情况。这个更新下载的是 WSL 运行时组件，走的是微软的分发网络，和 apt 镜像源完全是两回事，所以换了 apt 源也救不了它。

我的建议是：不要在下到一半的时候强行掐断进程，容易出现半更新状态；可以放到网络空闲时段重试，或者在 Windows 设置里检查一下微软商店的更新状态，确保 WSL 组件有更新的优先路径。如果你的网络环境对微软服务不太友好，多试几次、换一个时间段执行，能完成的概率会大很多。这个属于外部网络因素，不是配置可以解决的，大家量力而行。

6. 换完源之后，还有几个值得顺手做的优化

6.1 清理 apt 缓存和孤儿依赖

apt 每次下载的 .deb 安装包都会缓存在 /var/cache/apt/archives 目录下，日积月累非常占地方。WSL2 的虚拟磁盘文件是动态增长的，删了文件不会自动缩小，这也是很多人觉得"WSL 越用越胖"的原因之一。

定期清理是必须的：

bash复制sudo apt clean
sudo apt autoremove --purge

apt clean 清空下载缓存，autoremove --purge 移除不再被依赖的旧包及其残留配置。如果你发现清理之后 WSL 的虚拟磁盘文件还是很大，说明 VHDX 文件本身不会自动收缩。想真正释放 Windows 侧的磁盘空间，需要先关闭 WSL，再压缩虚拟磁盘：

bash复制wsl --shutdown

然后在 Windows 的管理员命令行里执行：

bat复制diskpart
select vdisk file="C:\Users\你的用户名\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu*\LocalState\ext4.vhdx"
compact vdisk
detach vdisk
exit

注意 你的用户名 和 CanonicalGroupLimited.Ubuntu* 里的具体路径要以你机器上的实际为准，可以用 PowerShell 的 dir 命令先找到 ext4.vhdx 的真实位置。压缩完磁盘空间能肉眼可见地多出来，非常解压。

6.2 镜像站不只是 apt：pip、npm、docker 也能用

最开始的思路如果只停在 apt，那就浪费了镜像站的价值。同一套镜像站通常还提供 PyPI、npm、Docker Registry、Conda 等多个生态的加速入口，顺手配一下能省下大量时间。

以阿里云镜像站的 PyPI 为例：

bash复制pip config set global.index-url https://mirrors.aliyun.com/pypi/simple/

之后 pip 安装 Python 包就走国内镜像了。npm 和 Docker 的配置稍微复杂一点，而且 Docker 镜像加速这类服务政策变动频繁，稳定性不如 apt 源。建议动手前先看一下对应镜像站官网的公告，确认当前推荐的可用地址，避免配了一个已经停服的旧地址。

6.3 保持更新习惯，定期处理系统升级

换完源之后，apt 的速度已经不再是阻碍，接下来要养成的是更新习惯。我建议至少每隔两三周执行一次：

bash复制sudo apt update
sudo apt upgrade

update 是刷新软件包索引，upgrade 是升级所有已安装软件到新版本。对 WSL 里的开发环境来说，安全补丁和工具链更新都很重要，避免积累太多版本差距之后升级出兼容问题。

如果你想更省心，可以安装 unattended-upgrades 做无人值守的安全更新：

bash复制sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

在弹出的界面里选择启用即可。安全补丁自动装，日常版本更新手动确认，这样既保证了安全性，又不会因为自动升级搞出意外。

我个人在实操中的体会是：换源这件事虽然简单，但它决定了一个开发环境能不能用起来。源配得好，后面所有软件安装都是顺滑的；源配得差，每天打开终端都像在赌人品。把换源这个动作练成肌肉记忆，再配合定期清理和更新，WSL 的开发体验才能真正称得上顺畅。最后再分享一个小技巧：把你常用的镜像站地址和 sed 替换命令存成一个 Markdown 笔记或者一键脚本，下次换新机器、重置 WSL 或者帮同事处理问题时，直接从笔记里复制，不用重新回忆，省下的时间绝对值得。