如果你问我过去几年里最划算的终端升级是什么，我会直接答：把默认 shell 换成 Zsh，再用 Oh My Zsh 做一套趁手的终端配置。这句话我在技术社区里说过很多次，每次都有刚从 bash 迁移过来的人回来说“相见恨晚”。原因很简单，Zsh 本身的补全、通配、提示符能力就比默认 bash 强一大截，而 Oh My Zsh 又把主题和插件管理做成了体系——装好之后，你要做的只是往配置里加几行，而不是从零拼凑一堆脚本。这篇文章我就按实际使用的顺序，把 Zsh 的安装、Oh My Zsh 的终端配置、插件管理、主题定制、Windows 下的落地方案，以及维护排错全部过一遍。不管你是刚入坑的新手，还是已经用了一阵想系统整理的老手，都能照着操作。
1. 先理清三层关系：Zsh、Oh My Zsh 和插件的分工
1.1 为什么要换：bash 能干活，但 zsh 更好干活
很多人有个误解，以为 Oh My Zsh 就是 Zsh，其实它们是完全不同的东西。Zsh 是一个 shell 程序，和 bash 是同一类角色，负责解释你在终端里敲的每一行命令。Oh My Zsh 则是基于 Zsh 的一套配置框架，它不替代 shell，而是把常用的 alias、函数、主题、插件全部封装好，让你不用自己写几百行配置就能获得一套可用的环境。插件则是更细粒度的功能包，有的给命令补全，有的给语法高亮，有的给 git 加一堆快捷别名。
那 Zsh 本身到底比 bash 强在哪？我挑几个日常最能感受到的。第一是补全，Zsh 的补全系统支持“部分匹配 + 模糊匹配”，你敲cd proj，它能补全到projects/，候选列表还可以用方向键直接翻页选择。bash 的默认补全相比之下更像“只能从头开始猜”。第二是通配符，Zsh 支持递归通配，**/*.log可以直接匹配当前目录下所有子目录里的 log 文件；还支持排除式匹配，比如ls *.txt~draft.txt可以列出除了 draft 以外的所有 txt 文件。第三是提示符，Zsh 原生支持右侧提示符、瞬时提示符，bash 想做到同样效果得靠外部工具或者写一大堆转义字符。
另外还有一个现实因素：macOS 在 Catalina 之前默认的 bash 一直停留在 3.2 版本，因为许可证问题不再升级，连${var,,}这种小写转换语法都不支持，写脚本时经常踩坑。Zsh 在 macOS 上则是持续更新的，这也是很多人换掉 bash 的直接导火索。
1.2 Oh My Zsh 到底帮你做了什么
如果你自己去配置 Zsh，第一步会卡在“不知道从哪里开始”。补全要调 zstyle，提示符要写 PROMPT 转义，历史记录要配 HISTFILE，这些零散知识点足以劝退大部分人。Oh My Zsh 的价值就在这里：它把社区公认的最佳实践打包成一个 git 仓库，装完之后你有了一套结构化的目录：
~/.oh-my-zsh/plugins/：官方自带插件的存放目录。~/.oh-my-zsh/themes/：官方主题目录。~/.oh-my-zsh/custom/：用户自定义目录，你加的插件、主题、脚本都可以放这里，升级时不会被覆盖。~/.zshrc：主配置文件，所有开关注册都在这里改。
它启动时会按固定顺序加载：先读.zshrc，再执行oh-my-zsh.sh，然后加载 lib 里的基础函数，接着按plugins=(...)数组逐个加载插件，最后应用主题和你自定义目录里的内容。理解了这个顺序，后面排错就容易多了：插件没生效，先去看它是不是在plugins=里，再看插件文件有没有被找到；主题有问题，先看ZSH_THEME变量是否指向了正确的主题名。
1.3 什么情况下其实不用折腾
我也得说句公道话，不是所有人都需要 Oh My Zsh。如果你只在终端里跑三五个命令，对补全和提示符没有要求，那默认 bash 完全够用，装上 Oh My Zsh 反而是负担。还有一种情况是生产环境或公司强管控的服务器，不允许随意安装软件、不允许改登录 shell，这时候老老实实用默认环境比什么都强。我的建议是：本地开发机、自己的个人服务器随便折腾；受控环境不要硬装，更不要把一套带个人配置的.zshrc直接拖到生产机器上，一旦依赖缺失，连登录都可能受影响。
2. 安装与切换：从 bash 到 zsh 的完整落地过程
2.1 各平台装 Zsh：macOS 和 Linux 两条主线
macOS 从 Catalina 开始默认 shell 就是 Zsh，所以新系统基本不需要额外安装，你先执行zsh --version看看版本。如果版本低于 5.8，建议用 Homebrew 装一份新的：brew install zsh，然后把新路径加到/etc/shells再去切换。
Linux 各发行版大同小异，都是先装包再切换：
# Debian / Ubuntu sudo apt update && sudo apt install -y zsh # Fedora / RHEL 系 sudo dnf install -y zsh # Arch / Manjaro sudo pacman -S zsh装完验证一下：which zsh，应该输出类似/usr/bin/zsh的路径。这一步别跳过，后面chsh要用到它。Windows 下面没有这么直接，我专门放到第 5 节讲。
2.2 切换默认 shell：chsh 的前提和那些坑
安装 Zsh 之后，系统默认 shell 还是 bash，你得手动切换：
chsh -s "$(which zsh)"然后重新打开一个终端窗口，执行echo $SHELL确认输出的是/usr/bin/zsh或/bin/zsh。这里有个最常见的坑：Linux 上chsh要求目标 shell 必须出现在/etc/shells文件里，否则会报non-standard shell。解决办法很简单，把这行加进去：
echo "$(which zsh)" | sudo tee -a /etc/shells如果是在容器里或者精简系统上，可能连chsh命令都没有，那就用usermod：
sudo usermod -s "$(which zsh)" "$USER"注意 WSL 里有时候chsh会提示 PAM 认证失败，这种情况多半是/etc/shells没配置好，或者当前用户不在允许变更的列表里。不想折腾的话，可以直接在 Windows Terminal 的配置文件里把启动命令行改成wsl -d Ubuntu -- zsh，或者用wsl --user指定用户进入后手动敲zsh。
2.3 安装 Oh My Zsh：官方脚本一条命令
Zsh 就绪后，安装 Oh My Zsh 非常简单，官方脚本一条命令搞定：
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"如果你的环境没有 curl，那就换 wget：
sh -c "$(wget -qO- https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"脚本会做几件事：检测 zsh 是否已安装，把现有的~/.zshrc备份成~/.zshrc.pre-oh-my-zsh，写入一份全新的模板配置，然后尝试把默认 shell 切到 zsh。装完以后，第一次进入 zsh 你会看到默认的robbyrussell主题，界面比较朴素，但已经带上了 git 分支信息。验证安装是否成功，可以执行omz version，能输出版本号说明命令已经挂好了。老版本用的是upgrade_oh_my_zsh，如果提示找不到omz，多半是安装包太老，手动更新一次就好。
2.4 第一次打开 .zshrc：模板配置里必须先认识的变量
装完 Oh My Zsh，~/.zshrc里会出现一堆默认配置。我建议你先把这几个变量认全，其余的先不动：
| 变量 | 作用 |
|---|---|
ZSH | Oh My Zsh 的安装路径，默认~/.oh-my-zsh |
ZSH_THEME | 当前使用的主题名 |
plugins | 要加载的插件列表，用空格隔开 |
ZSH_CUSTOM | 自定义目录路径，默认$ZSH/custom |
HISTSIZE/SAVEHIST | 历史命令的内存记录数和持久化条数 |
DISABLE_AUTO_UPDATE | 设为true可关闭自动更新检查 |
ENABLE_CORRECTION | 设为true可开启命令拼写纠正 |
.zshrc是你整个环境的入口，后面加插件、换主题、写 alias 都改这个文件。改完记得source ~/.zshrc重新加载，或者干脆新开一个终端窗口。
3. 插件管理：体验差距几乎全在这个环节
3.1 plugins=() 数组和插件加载逻辑
Oh My Zsh 的插件系统说穿了很简单：plugins=(git z sudo extract)这个数组列出要加载的插件名，启动时框架会去plugins/和custom/plugins/目录里找同名插件，然后逐个source插件下的.plugin.zsh文件。插件文件里定义的东西无非是别名、函数、自动补全规则、按键绑定这几类。
这里有两个细节值得记住。第一，加载顺序严格按照数组顺序执行，所以顺序是有意义的。比如zsh-syntax-highlighting必须放在所有插件最后，因为它要接管命令行的语法高亮渲染，加载太早会被其他插件覆盖。第二，外部插件默认不会出现在官方plugins/目录里，统一放到custom/plugins/下面，这样升级 Oh My Zsh 时不会被清掉。
3.2 官方内置插件里我最推荐的组合
官方仓库自带一百多个插件，但日常真正值得开的其实就那么几个。我的长期配置是plugins=(git z sudo extract)，原因如下：
git：给 git 提供一大票短别名，gst是 status，gaa是 add all，gcmsg是 commit，gp是 push，gl是 pull，gd是 diff，glg是 log。用习惯之后你会发现敲命令的频率直线下降。z：按访问频率记录目录，输z proj就能跳到任何一个名字里带 proj 的目录，比cd加 tab 补全省事太多。sudo：连续按两下 Esc，自动给当前命令加上sudo前缀。比如你敲了vim /etc/nginx.conf，按两下 Esc 就变成sudo vim /etc/nginx.conf，不用把光标移到行首再手工补。extract：一个extract命令解压七八种压缩包。tar.gz、zip、7z、rar 全走同一个入口，再也不用记参数。
git 插件的别名表格，我整理几个最常用的供参考：
| 别名 | 对应命令 | 用途 |
|---|---|---|
gst | git status | 查看状态 |
gaa | git add --all | 暂存所有改动 |
gcmsg | git commit -m | 提交 |
gp | git push | 推送 |
gl | git pull | 拉取 |
gco | git checkout | 切换分支 |
glog | git log --oneline --decorate --graph | 查看精简日志 |
如果你觉得z还不够聪明，现在社区更推荐 Zoxide，安装后在.zshrc里加一行zoxide init zsh，用法类似但匹配算法更强，值得一试。
3.3 两个必须手动装的外部插件：语法高亮和自动建议
如果说内置插件是锦上添花，那下面这两个外部插件就是质的飞跃。第一个是zsh-syntax-highlighting，它的效果是：你敲命令的时候，合法命令显示绿色，不存在的命令显示红色，路径、参数、引号都有不同颜色。输入错误当场就能看出来，不用等到回车才知道命令不存在。第二个是zsh-autosuggestions，它会根据你的历史记录在当前输入行灰显一个建议，按右方向键一键接受，几乎是本地开发必备的效率工具。
安装方式一致，都是 clone 到custom/plugins/目录：
git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions git clone https://github.com/zsh-users/zsh-syntax-highlighting ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting然后编辑.zshrc，把插件名加进去，注意zsh-syntax-highlighting一定要在最后：
plugins=(git z sudo extract zsh-autosuggestions zsh-syntax-highlighting)最后source ~/.zshrc。第一次回车后你会明显感觉到终端“活了”，颜色、建议、补全全部到位。这个感受是文字描述不出来的，装上你就懂。
3.4 custom 目录：把团队脚本和个人 alias 也纳入管理
很多人不知道，Oh My Zsh 的custom/目录下所有.zsh文件会在启动时自动加载，所以个人 alias、团队共享函数都可以直接丢进去，不用全部堆在.zshrc里。我自己的习惯是维护一个~/.oh-my-zsh/custom/alias.zsh，里面放和项目相关的短命令：
# ~/.oh-my-zsh/custom/alias.zsh alias gcb="git checkout -b" alias dc="docker-compose" alias kc="kubectl" alias ds="docker ps --format 'table {{.Names}}\t{{.Status}}'"这样.zshrc保持干净，团队成员之间的配置差异也更容易通过 dotfiles 仓库同步。如果你在公司内网有一批公共脚本，可以把它们放在custom/下某个子目录里，再用fpath加进函数搜索路径，同样能自动生效。
4. 主题与提示符：让每个终端窗口都有信息量
4.1 主题机制和默认主题的局限
主题在 Oh My Zsh 里就是定义PROMPT和RPROMPT等提示符变量的脚本，文件存在themes/目录下，以.zsh-theme结尾。.zshrc里改一个ZSH_THEME="xxx"就能切换，支持在custom/themes/放自己的主题。
默认主题robbyrussell最大的问题是信息量太少：只显示用户名、主机、当前目录和 git 分支，没有 git 工作区状态，没有上一条命令的执行状态，没有 Python 虚拟环境提示。开发的时候经常要来回执行git status和echo $?去确认状态，效率很低。所以我的建议是，装完 Oh My Zsh 后的第一步不是堆插件，而是先换一个信息完整的主题。
4.2 Powerlevel10k 的安装与配置
目前在 Zsh 主题里体验和性能平衡得最好的，依然是 Powerlevel10k。它的安装方式同样是 clone 到 custom/themes：
git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k然后在.zshrc里改一行：
ZSH_THEME="powerlevel10k/powerlevel10k"重启终端后会进入交互式配置向导，按提示选一遍提示符样式、符号风格、是否显示时间、是否显示执行时长等。配置结果保存在~/.p10k.zsh里，后续想微调可以重新执行p10k configure，或者直接打开~/.p10k.zsh改参数。
我建议在向导里开启这几个元素：当前目录、git 分支和干净/脏状态、上一条命令的退出码（非零时才显示）、命令执行时长、Python 虚拟环境。这些都是开发时的高频信息，其余像系统负载、当前时间之类看着热闹但实际很少关注的东西，能关就关，提示符太满反而影响阅读。
如果你不想让提示符绑定在某个框架上，也可以考虑 Starship。它是独立的跨 shell 提示符，用eval "$(starship init zsh)"接入，配置走 TOML 文件，干净且可移植。缺点是它是个外部进程，提示符渲染速度比 Powerlevel10k 内置方案稍慢一点，但在可接受范围内。
4.3 字体是主题的隐形门槛：为什么图标全是方块
换完 Powerlevel10k 后很多人会遇到的第一个问题是：提示符里的分支图标、箭头全是方块或问号。这不是主题坏了，是你终端缺少对应字体。Powerlevel10k 和大部分现代主题都使用 Nerd Font 定制的特殊字符，不支持这些字符的字体只能显示成占位方块。
解决办法是安装 MesloLGS NF 或任意一款 Nerd Font，然后在终端设置里手动选择字体。不同终端的位置不太一样：
- macOS 自带的 Terminal：偏好设置里选描述文件，修改字体。
- iTerm2：Preferences → Profiles → Text → Font。
- Windows Terminal：设置 → 配置文件 → 外观 → 字体。
- VS Code 集成终端：设置
terminal.integrated.fontFamily为"MesloLGS NF"。
改完重启终端，图标就正常了。这个坑几乎每个新人都会踩一遍，所以提前说出来，省得你以为是主题没装好。
5. Windows 上跑 Oh My Zsh：三条路线，按使用场景选
5.1 路线首选 WSL：等于把 zsh 放进 Windows
Windows 上的 Oh My Zsh 搜索热度一直很高，但很多教程一上来就直接给 Git Bash 方案，容易把人带偏。我的建议很明确：如果你有选择余地，优先用 WSL。原因是 Zsh 和 Oh My Zsh 生态本来就是 Linux 原生世界的东西，在 WSL 里安装、升级、排错都和在 Ubuntu 服务器上完全一致，最不容易出幺蛾子。
启用 WSL 只需要在管理员终端里执行：
wsl --install -d Ubuntu装完进入 Ubuntu，然后走第 2 节的 Linux 安装流程：apt install zsh、chsh -s $(which zsh)、跑 Oh My Zsh 安装脚本。Windows Terminal 会自动识别 WSL 发行版并生成配置文件，你也可以在设置里调整启动目录和字体。文件访问上，Windows 的 C 盘是挂在/mnt/c下的，比如C:\Users\你的名字\Projects对应/mnt/c/Users/你的名字/Projects。
一个性能相关的经验：在 WSL 里做开发时，项目代码最好放在 WSL 默认的文件系统里，比如/home/你/project，不要直接放在/mnt/c下。因为/mnt/c是跨系统协议访问 Windows 文件系统，IO 慢一个量级，跑测试、装依赖的时间会明显变长。如果已经放在 Windows 盘了，可以用git mv挪到 Linux 目录再继续开发。
5.2 Git Bash 里跑 zsh：不装 WSL 的轻量折中选择
如果你暂时不想碰 WSL，只想在 Git Bash 里体验 zsh 和 Oh My Zsh，这条路也能走通，但要接受它的局限性。Git for Windows 自带的是 bash，不是 zsh，要从 MSYS2 的软件源里拿一个 zsh 的软件包塞进 Git 的目录里。社区比较通行的做法是：去 MSYS2 仓库下载对应架构的zsh包（类似zsh-5.9-1-x86_64.pkg.tar.zst），用解压工具解开后，把usr/bin下的 zsh 相关文件释放到 Git 的安装目录对应位置，让 Git Bash 能找到zsh命令。解压命令可以用tar --zstd -xf 包名 -C "安装目录"。
走这条路有两个前提：包版本要和 Git 自带的 MSYS2 运行时兼容，架构必须一致。你每次升级 Git for Windows 之后，以前塞进去的 zsh 有可能失效，需要重新放一遍。所以我不太推荐对终端不熟的读者在这条路上死磕。它适合那种“公司电脑装不了 WSL 但真的很想要 zsh”的场景，折腾成本你们要清楚。
5.3 MSYS2 / Cygwin 与 Windows Terminal 配合
比 Git Bash 更干净一些的方案是直接使用 MSYS2 环境。MSYS2 自带完整的包管理器 pacman，在它的终端里执行：
pacman -Sy zsh git curl然后照常跑 Oh My Zsh 安装脚本。装完之后，MSYS2 的安装目录下usr/bin/zsh.exe就是你的 zsh。Windows Terminal 里新增一个配置文件，命令行填：
C:\msys64\usr\bin\zsh.exe环境变量建议加一个MSYS2_PATH_TYPE=inherit，让系统能继承 Windows 的 PATH，这样code、docker这类 Windows 侧安装的命令在 MSYS2 里也能直接敲。Cygwin 也是一条老路，但它额外的包管理配置更繁琐，除非你有历史包袱，否则我不建议新用户从 Cygwin 起步。
5.4 Windows 路径、编码和常见坑对照
在 Windows 上折腾终端，最容易混淆的是路径表达。放一张对照表，贴到笔记里比什么都管用：
| 场景 | WSL | Git Bash / MSYS2 |
|---|---|---|
| Windows 用户目录 | /mnt/c/Users/name | /c/Users/name |
| Windows 桌面 | /mnt/c/Users/name/Desktop | /c/Users/name/Desktop |
| 当前盘符访问 | 通过/mnt/<盘符> | 通过/<盘符>/ |
| 换行符 | Linux LF | 注意core.autocrlf是否设为input |
| 中文文件名 | 需要 UTF-8 locale | Windows Terminal 设为 UTF-8 |
还有一个很常见的问题：在 Git Bash 里用 zsh，如果.zshrc里写了 Linux 专属路径，比如/home/name/.zshrc，那实际路径应该是C:\Users\name\.zshrc映射过来的~/.zshrc。在 MSYS2 里$HOME默认是C:\msys64\home\name，跟 Git Bash 的$HOME不是同一个地方，这也是很多人明明装了 Oh My Zsh 配置文件却找不到的原因。遇到类似情况，先echo $HOME看看到底指向哪，再决定把配置放在哪里。
6. 启动速度、升级维护与高频报错排查清单
6.1 先量化启动时间，再决定要不要优化
Oh My Zsh 加载几十个函数和插件，必然比裸 zsh 慢一点。判断慢不慢，不要靠感觉，先测。最简单的办法：
time zsh -i -c 'echo done'-i表示以交互模式启动，-c执行完命令后退出，输出的 real 时间就是一次完整加载耗时。如果你想看加载过程中每个模块各自花了多少时间，可以用自带的 profiler：在.zshrc最顶部加一行zmodload zsh/zprof，开一个新终端，然后执行zprof，它会列出每个函数的耗时占比。排查完记得把这行删掉，不然每次启动都会记录性能数据，反而拖慢速度。
经验值参考：300ms 以内的启动时间感知不明显，500ms 以上就值得优化了。如果你的机器配置一般还能扛住，其实可以先把精力放在功能上，不用过度追求 100ms 级别的极致启动。
6.2 提速三板斧：剪插件、延迟加载、关更新
第一板斧是精简插件。很多人装插件是看到推荐就加，一个不落的后果是启动时 source 一堆用不上的文件。我自己的原则是：内置插件不超过六个，外部插件不超过三个。插件列表里常年只保留确实会用的，不用的果断删掉。
第二板斧是延迟加载。像nvm、pyenv、conda这类初始化脚本动辄几百毫秒，如果每次都随 shell 启动加载，终端必然卡。更合理的做法是让它首次使用时再初始化。举个 nvm 的例子：
load_nvm() { export NVM_DIR="$HOME/.nvm" . "$NVM_DIR/nvm.sh" } alias nvm='load_nvm && nvm'这样平时启动不碰 nvm，只有真正敲nvm命令时才加载。代价是第一次加载会有短暂卡顿，但后续再用就完全正常。类似思路可以套用到任何启动脚本上。
第三板斧是关闭自动更新。Oh My Zsh 默认会不定期检查更新并弹提示，这个行为对效率是纯干扰。在.zshrc里加一行：
DISABLE_AUTO_UPDATE="true"需要更新时手动执行omz update就好，主动权握在自己手里。
6.3 高频报错排查表，对着抄就行
这些年我也帮人排查过不少 Oh My Zsh 问题，大多数集中在几个固定原因上。整理成一张表，遇到直接对号入座：
| 现象 | 原因 | 处理方法 |
|---|---|---|
| 启动提示 “Insecure completion-dependent directories detected” | 目录权限里有 group write，zsh 安全校验不通过 | 执行chmod g-w ~/.oh-my-zsh并递归处理子目录，或compaudit -i |
| 主题图标全部是方块/问号 | 终端缺少 Nerd Font 字体 | 安装 MesloLGS NF/Nerd Font，并在终端设置里选中 |
| 新加的插件没生效 | 没写入plugins=或插件目录名拼错 | 检查custom/plugins/下目录名，改完source ~/.zshrc |
zsh-syntax-highlighting导致补全报错 | 插件加载顺序太靠前，和补全覆盖冲突 | 把它挪到plugins=(...)数组最后一个 |
chsh报 non-standard shell | /etc/shells缺少 zsh 路径 | 把which zsh的结果追加到/etc/shells |
| 提示符里显示上次命令的错误码乱跳 | 主题没有配好 exit code 段 | 重跑p10k configure，确认打开了退出码段 |
omz: command not found | Oh My Zsh 版本过老 | 手动执行upgrade_oh_my_zsh后重新装最新版 |
记住一个万能调试入口：omz doctor会检查 zsh 版本、目录权限、插件路径等常见项目，很多问题它自己就能查出来。遇到异常先跑一遍再动手。
6.4 维护习惯：什么时候更新，什么时候别手欠
Oh My Zsh 的更新节奏我一般是“季度性”。每次omz update之前，至少确保.zshrc能被 git 管理，或者已经备份。我自己的做法是把.zshrc和custom/下的私有配置放进一个 dotfiles 仓库，换机器时拉下来做个软链接就能恢复。这里有个细节：.oh-my-zsh本体不要提交到 dotfiles 仓库，它体积大、升级频繁，而且随时可以从官方重新安装；要管理的只是你自己写的那部分。
在生产服务器或个人长期运行的实例上，我更倾向于只做保守更新：除非遇到安全公告或明确需要的 bug 修复，否则不主动升级。因为 Oh My Zsh 自带插件和主题改动频繁，某次升级可能改变某个插件的别名或行为，打乱你习惯的命令。个人开发机就可以放开一点，遇到新功能可以及时尝鲜。
最后分享一个我的个人习惯：新装环境后，先做一次omz update确保框架处于最新状态，再安装字体、克隆外部插件、设置主题，最后才动.zshrc。这样能把“框架问题”和“配置问题”分开排查——如果后续出了毛病，至少知道不是初始安装版本太旧导致的。这套流程我用了很多年，从 macOS 到 Linux 再到 WSL，基本都是一遍过。
