如果你的终端也和我之前一样每次新开一个窗口总要等上半秒到一秒提示符才慢悠悠地出现那你大概率装着 Oh My Zsh而且插件越装越多主题也从 default 一路换到了什么都想显示的全能型主题。我以前也是标准的 OMZ 重度用户插件装了二十多个主题用 powerlevel10k.zshrc里塞满了 export、alias、source以及在各种教程里抄来的片段。换来的是启动耗时经常接近一秒进到稍微大一点的 Git 仓库时cd进去还要再等一轮提示符才肯出来。后来我花了一个周末把主题部分切到 Starship顺带做了一点减法启动时间从接近一秒降到几十毫秒这个改动是我近几年在终端体验上性价比最高的一次。下面这篇文章会把我这次折腾的完整过程写清楚它到底替换的是 Oh My Zsh 的哪一层、怎么装、怎么配置、实测能快多少、有哪些坑要先避开。适合所有正在用 OMZ 但觉得启动越来越慢的人也适合刚听说 Starship、想搞清楚它和 OMZ 是什么关系的人。1. 开个终端要等一秒你受得了吗先说说那个让人抓狂的场景。我习惯开一堆终端窗口一个跑本地服务一个连公司跳板机一个随手写点临时命令。以前每次打开新窗口先看到光标在左上角闪几下那段时间终端其实是“静默”的你敲什么它都不反应要等提示符真正跳出来才能输入。如果是在 tmux 里开新窗格或者在 IDE 里拉起一个内置终端这个延迟会被放大得更明显因为整个环境冷启动没什么可缓存的。有的朋友可能觉得几百毫秒而已至于吗但开发时人的注意力是很脆弱的。你脑子里想的是“下一步敲什么命令”结果指尖已经按下去了终端却没响应那种割裂感比慢本身更伤人。尤其是需要频繁开终端的场景比如跑测试、开日志、起 Docker、切环境一天下来“等待终端就绪”的时间累积起来很可观。我那时候的配置大概是这样的Oh My Zsh 主体二十个左右插件包括 git、docker、kubectl、brew、zsh-syntax-highlighting、zsh-autosuggestions、extract、sudo 等等主题是 powerlevel10k开了信息量很大的配置git 分支、git 状态、Python 虚拟环境、Node 版本、命令耗时全都显示还装了 nvm官方安装脚本自动往.zshrc里塞了一段加载逻辑这套组合在新款 MacBook 上启动一次交互式 zsh稳定在 700ms 到 1000ms 之间。进一个大一点的 monorepo第一次渲染提示符还能再让你等个几百毫秒。后来我去了一台弱一点的 Linux 服务器上测试直接奔着 1.2s 去了。说实话这个数字在很多“终端性能优化”文章里都算正常水平但正常不代表合理。一个 shell 而已凭什么要加载这么久才能在光标前画出一个❯Startship 解决的就是这个问题。它不修改你的插件框架也不帮你管理别名和环境变量它只管一件事用足够快的速度把提示符渲染出来。因为它是用 Rust 写的单二进制程序渲染 prompt 的逻辑全部独立在 shell 进程之外还带了子进程超时保护所以最坏情况也就是某个模块超时丢掉不显示而不是整个终端卡在那等。在动手换之前我建议你先做一件事量化自己的启动耗时。这是整个优化的基础。2. 为什么 Oh My Zsh 越用越慢插件、主题与版本管理的叠加效应2.1 先量化你的启动耗时别靠“感觉”不要凭感觉说“我的终端挺快的”或者“我的终端好慢”先跑一个命令把数据拿出来。# 重新开一个终端窗口然后执行 /usr/bin/time -p zsh -i -c exit输出里real那一列就是这次启动的墙钟时间。-i表示以交互模式启动这样.zshrc才会被加载-c exit的意思是启动后立刻退出只测启动过程本身不掺杂后续命令的执行时间。建议跑 5 次取中位数因为第一次冷启动会受磁盘缓存影响通常比后面几次慢。我那时候跑出来的结果中位数是 0.85s 左右看实数据比看“感觉”直观多了。你测出来如果超过 300ms就值得往下看如果只有 50ms那其实没必要折腾你的配置已经很克制了。2.2 插件的加载方式决定了它的天花板Oh My Zsh 的启动流程说复杂不复杂。你的.zshrc里有一行source $ZSH/oh-my-zsh.shOMZ 会做这几件事加载lib目录下的一堆基础函数文件比如 git、clipboard、history、theme 等模块的辅助函数加载你指定的主题脚本遍历plugins(...)数组里声明的插件把每个插件目录下的*.zsh文件按顺序source一遍问题就出在第三步。插件越多被 source 的 shell 脚本就越多而且这些脚本不能并行加载只能一个个来。很多插件又不是几行别名那么简单zsh-syntax-highlighting要在启动时注册 zle 的钩子把输入框里的命令变成颜色高亮这需要初始化一套规则和事件zsh-autosuggestions要初始化补全引擎和词库加载量也不小docker、kubectl、brew这类插件虽然本身逻辑不多但它们引入的补全函数一个比一个大叠加起来启动时间从几十毫秒跳到几百毫秒是非常正常的。关键是这些插件里的很多东西你只是“装着而已”真正用到的可能只有一小部分。比如我为docker-compose装的补全一个月也用不了几次但每次开终端都要白白加载一遍。2.3 真正的“大头”往往不是 OMZ 本身如果你测出来启动非常慢先别急着把所有责任都推给 Oh My Zsh有几个常见的“隐形杀手”往往比 OMZ 本身更占时间。第一个是 nvm。它的官方安装方式会在你的.zshrc里塞一段export NVM_DIR... [ -s $NVM_DIR/nvm.sh ] . $NVM_DIR/nvm.sh意思是每次新开终端都要完整执行一遍nvm.sh而nvm.sh内部会扫描你安装的所有 node 版本目录解析路径、设置别名。版本装多了之后非常拖时间我实测过光是 nvm 这一项就能吃掉 200-400ms。第二个是 pyenv、conda、fvm 这类环境管理工具的初始化脚本。它们的原理都差不多在交互式 shell 启动时执行一段比较重的初始化如果你同时装了 pyenv 和 conda叠加效果更明显。第三个是主题。OMZ 默认主题还好普通机器上也就几十毫秒。但如果你的主题是 powerlevel10k 或者类似的信息密集型主题那每次提示符渲染时都要去同步获取 git 分支、git 状态、远程领先落后多少个提交、当前 Python 虚拟环境名字、上一次命令执行耗时……这些信息大多来自git status、git rev-parse这种命令在小型仓库里还好在几百 MB 的 monorepo 里同步执行一次很容易超过几百毫秒。p10k 其实已经对这个做了很多优化还提供了 instant prompt 这种缓存方案但它的 instant prompt 有使用限制本质上是在“绕过”不是从根上减小开销。而且主题本身这么多信息在一个提示符里视觉上也未必是好事。还有一个很多人没注意到的点如果你用了 zplug、antigen 这类插件管理器它们默认可能会在每次启动时检查插件更新去访问 GitHub 或对应仓库网络一旦慢启动时间直接被拖上天。所以总结下来OMZ 慢不是单一原因是“插件数量 重型环境初始化 主题渲染”三层叠加的结果。你想优化就是把这三层都按到合理水平——Starship 恰好对“主题渲染”这一层做了专门优化。3. 动手前先搞懂Starship 和 Oh My Zsh 的边界在哪里3.1 Starship 只解决“提示符”这一件事Starship 官方对自己的定位叫 “cross-shell prompt”翻译过来就是跨 shell 的提示符引擎。它不是一个 zsh 配置管理框架不碰你的别名不管理插件不设置 PATH 环境变量。它只负责在你敲命令之前把那一行提示符画出来。Oh My Zsh 则是一个 zsh 专属的配置框架覆盖了插件加载、主题、别名、更新机制等多个方面。这两个东西真正重叠的部分只有一个主题也就是提示符的最终呈现。明白这一点很重要因为很多人装完 Starship 以后以为可以整个卸载 OMZ 了结果发现自己的git别名、各种插件补全全部没了一脸懵。更准确的说法是Starship 是 Oh My Zsh 的“主题层”替代品不是整个 OMZ 的替代品。如果你的需求是从一大堆主题配置里解放出来同时保留 OMZ 帮你管理的插件那“继续留着 OMZ只把主题交给 Starship”是完全可行的操作。如果你想要极简启动、连 OMZ 本身都不想加载那需要另外解决插件问题我下面会给出方案。3.2 Starship 快的原理并行子进程与强制超时Starship 快不是玄学底层逻辑很清晰。第一它是用 Rust 写的单二进制文件启动一个进程的代价比执行上百行的 shell 脚本小得多。第二它在每次渲染提示符时会并行启动一些子进程去收集环境信息比如当前 git 仓库的状态、当前目录下的编程语言版本、是否需要显示某些模块。这些子进程和 shell 主进程是隔离的shell 不会被它们里头的某条慢命令彻底阻塞。第三也是最关键的它有强制超时机制。Starship 里有一个顶层配置command_timeout默认 500ms。任何模块的子进程如果在这个时间内没有返回结果就直接放弃显示该模块绝不会无限期等下去。这就是为什么在特别大的 git 仓库里Starship 即使拿不到状态提示符也能很快出现——它选择不展示而不是死等。传统主题做不到这一点因为它们是直接在 shell 进程里同步执行git status的仓库大一点就只能陪着等。第四Starship 的模块是“按需激活”的。比如[nodejs]模块只有当当前目录里有package.json、node_modules或者.js文件时才被激活[git_commit]模块只有当你显式开启了才会去查询 commit 信息。目录里什么都没有时大部分模块根本不启动开销自然低。3.3 迁移前想清楚职能分配所以你在动手之前先想清楚自己属于哪种情况情况处理方式只用 OMZ 的主题功能插件基本不用直接把主题停掉装 Starship最干净主题和插件都在用但插件离不开保留 OMZ 的插件管理只关掉或降级主题让 Starship 接管提示符想从根上减少每次启动的加载量把 OMZ 整个拿掉插件逐个换成单独安装的轻量方案Starship 做提示符有跨 shell 或者多机一致性的需求Starship 的配置是同一个 toml 文件bash、zsh、fish、PowerShell 通用最后一种情况很多人容易忽略。Starship 在 macOS、Linux、Windows 下的提示符渲染逻辑完全一样你只需要同步一个配置文件不需要像 OMZ 那样分别维护 zsh 和 bash 的主题语法。我自己就是被这个跨 shell 一致性打动才决定把它当成长期方案的。4. 迁移实录安装 Starship、替换主题并保住插件4.1 安装与验证先装本体不同平台命令不一样# macOS brew install starship # Linux / WSL也可以直接用官方脚本 curl -sS https://starship.rs/install.sh | sh # Windows winget install --id Starship.Starship # 或者配置过 scoop 的人可以用 # scoop install starship装完先确认一下starship --version能打印出版本号就说明装好了。注意官方安装脚本默认装到/usr/local/bin如果提示没有权限可以加--force加上自定义参数重新执行或者直接用 brew / 发行版包管理器安装省心一些。4.2.zshrc改造关掉重型主题并启动 Starship先备份一份你的.zshrc这个动作在任何配置修改前都值得做cp ~/.zshrc ~/.zshrc.bak然后编辑~/.zshrc。如果你是 p10k 用户第一件事是把 p10k 的初始化注释掉。常见的 p10k 初始化长这样# source /usr/local/share/powerlevel10k/powerlevel10k.zsh-theme # [[ ! -f ~/.p10k.zsh ]] || source ~/.p10k.zsh注释掉之后再把 OMZ 的主题设置改一下。这里有一个很多人容易踩的细节OMZ 在ZSH_THEME为空字符串时会自动回退到 robbyrussell所以别指望设成空字符串来“禁用主题”。你可以直接保留默认主题反正 Starship 会在后续步骤接管提示符多加载一个几十行的默认主题脚本影响很小。# 如果你之前设置了 powerlevel10k注释掉上面那两行 # 然后这里保留默认主题即可Starship 最终会覆盖显示 ZSH_THEMErobbyrussell最后在.zshrc文件末尾追加eval $(starship init zsh)为什么放在最后一个朴素但有效的理由.zshrc里的设置遵循“后加载覆盖先加载”的直觉把 Starship 初始化放在最后能最大程度避免后面某个脚本或者别名把它的 preexec / precmd 钩子或者PROMPT覆盖掉。如果你以后又加了其他自定义 prompt 配置也尽量保持这个顺序。保存后重新开一个终端窗口验证。你应该能看到提示符已经变成默认的 Starship 风格一行带 git 分支路径后面的箭头符号是❯。如果没变化先检查.zshrc里是不是还有别的地方 source 了其他主题或 prompt 初始化脚本。4.3 最简配置先跑起来再谈美化Starship 默认配置已经能用了不需要写任何配置文件。我第一次跑起来的时候提示符会显示当前目录长路径自动截断git 分支名如果目录里检测到 package.json显示当前 Node 版本如果检测到 Git 工作区有未提交状态显示对应的符号这些信息的渲染速度我体感几乎和裸 shell 一样。如果想让提示符更符合自己的习惯可以创建配置文件# ~/.config/starship.toml add_newline true [character] success_symbol [❯](bold green) error_symbol [❯](bold red) [git_branch] symbol 这几行配置的含义是命令成功后提示符是绿色高亮的❯失败变成红色git 分支前显示一个空符号省掉默认的图标。配置写好之后不需要重启终端只要新开一个终端窗口就会自动加载。如果没有生效用下面命令看看当前实际生效的配置starship print-config想直接打开配置文件编辑比较新的 Starship 版本支持starship config它会用你的系统编辑器打开~/.config/starship.toml不存在时会自动创建。4.4 把 OMZ 也卸掉保留高亮和自动补全的轻量方案如果你走完上面几步之后还想进一步降低启动时间可以考虑把 Oh My Zsh 整个拿掉。毕竟 OMZ 的主框架本身也有底噪虽然它没主题那么重但和裸 zsh 比起来还是有差距。卸载其实就是把.zshrc里的source $ZSH/oh-my-zsh.sh注释或删掉。但直接删会带走你所有插件所以先从最离不开的两个插件开始补回来语法高亮和自动补全。这两个是很多 OMZ 用户最常用的插件也是完全独立于 OMZ 的可以单独 clone 下来 sourcemkdir -p ~/.zsh/plugins git clone https://github.com/zsh-users/zsh-autosuggestions ~/.zsh/plugins/zsh-autosuggestions git clone https://github.com/zsh-users/zsh-syntax-highlighting ~/.zsh/plugins/zsh-syntax-highlighting然后在.zshrc里去掉 OMZ 加载行加上source ~/.zsh/plugins/zsh-autosuggestions/zsh-autosuggestions.zsh source ~/.zsh/plugins/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh这里有一个非常关键的顺序zsh-syntax-highlighting一定要放在.zshrc的最后面加载。因为它会重新绑定 zle 的某些回路如果后面还有其他脚本很容易把它的高亮规则或者之前定义的快捷键覆盖掉。这个坑我当初也踩过症状就是自动补全还能用但高亮时有时无。其他需要的插件比如git别名、kubectl补全之类可以根据自己的情况去对应项目仓库单独 clone然后逐个 source。别名和 PATH 就自己在.zshrc里按需写一开始可能不太习惯但慢慢会发现自己的配置干净了很多启动速度和 unicorn 一样轻盈。去掉 OMZ 之后加上 Starship 的完整.zshrc风格大概就是这样export PATH$HOME/.local/bin:$PATH source ~/.zsh/plugins/zsh-autosuggestions/zsh-autosuggestions.zsh source ~/.zsh/plugins/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh eval $(starship init zsh)整个文件也就十几行每个配置是什么用途一目了然。5. 数字说话加速前后的启动耗时对比5.1 测试方法与我所用的组合为了让你对提升幅度有个更直观的认知我把常见几种配置组合放到同一台 Linux 云主机上做了个简单的基准测试。测试方法就是第一节写的/usr/bin/time -p zsh -i -c exit每种组合跑 5 次取中位数。需要注意一个前提测的这台机器是个干净的 2C4G 云服务器网络还算稳定磁盘是 SSD 但性能一般大致相当于一个“不拖后腿但也谈不上高性能”的普通开发环境。我对比了这几组裸 zsh没有任何配置OMZ 默认配置 几个常用插件OMZ 20 个插件 powerlevel10k 信息主题OMZ 保留插件管理但主题降级为默认叠加上 Starship去掉 OMZ只保留 zsh-syntax-highlighting 和 zsh-autosuggestions再加上 Starship去掉 OMZ无插件只有 Starship5.2 结果对比与解读被测组合启动耗时中位数裸 zsh20-40msOMZ 几个常用插件150-300msOMZ 20 插件 powerlevel10k700-1200msOMZ关主题 Starship100-200ms无 OMZ 高亮/补全插件 Starship60-110ms无 OMZ 无插件 Starship30-50ms这个表格里的数值会因为你机器的 CPU、磁盘、具体插件版本而波动但量级关系是稳定的。有两个结论值得强调第一最大的收益来自“放弃重型主题 减少插件加载”这两个动作的叠加而不是 Starship 单点魔法。用 p10k 时 700-1200ms换到 OMZ 默认主题就已经少了一大截再切到 Starship 又进一步。第二就算你完全保留 OMZ 框架只把主题层切到 Starship从 700ms 降到 100-200ms 也已经是体感上“从明显卡顿到接近秒开”的跨越。如果你不想动插件结构这个方案收益已经很可观。5.3 为什么多次测量会有波动你可能自己回去测的时候发现数值和我们表格里的不太一样甚至每次跑出来都不一样。这很正常和下面几个因素有关磁盘缓存第一次冷启动会把相关脚本和二进制读入内存后续再测会快很多所以总强调取中位数而不是第一次nvm / pyenv 的安装脚本位置它们每次启动都要重新解析目录如果配置的网络路径较慢时间波动很大终端模拟器的渲染开销gnome-terminal、iTerm2、Windows Terminal 的字体和样式渲染方式不同会影响你主观感受Starship 的异步特性它的模块信息是子进程并行收集的单次偶尔会因为系统负载多几十毫秒但一般不会超过超时阈值所以看数据的时候不要纠结“到底是 62ms 还是 85ms”而是要问自己这个延迟在可接受范围内吗从接近一秒降到几十毫秒带来的体验提升是跨档次的。还有一个反直觉的地方Starship 每次渲染提示符并不是零开销的它也要启动一个 Rust 进程去收集信息。但因为子进程模式 超时保护它的开销通常只有几十毫秒而且不会出现“卡着不动”的局面。相比之下p10k 在仓库大时是真的会停在那里等 git 命令回来的。6. 进阶调优自定义配置、字体图标与大型仓库卡顿6.1 图标变方块先换字体装完 Starship 第一次打开你可能会发现提示符里有些字符变成方块或者问号尤其是 git 分支和语言版本前面的小图标。这不是 Starship 坏了而是你的终端字体里没有包含 Nerd Font 的特殊字符。Starship 的默认提示符和模块图标大量使用 Nerd Font 符号而 macOS 自带的 Menlo、Linux 常见的 Monospace 字体都不带这些 glyph。解决方案有两个方案一也是推荐方案安装一个 Nerd Font 字体然后在终端设置里把字体切过去。常见的推荐有 FiraCode Nerd Font、JetBrainsMono Nerd Font、MesloLGS Nerd Font。macOS 上可以用 Homebrew 搜索相关包来装比如brew install --cask font-meslo-lg-nerd-font装完之后iTerm2Preferences - Profiles - Text - Font选择对应的 Nerd FontWindows Terminal设置 - 配置文件 - 外观 - 字体GNOME Terminal偏好设置 - 配置文件 - 自定义字体方案二不想折腾字体的话把模块的 symbol 都换成普通 ASCII 字符能接受就接受。比如在[git_branch]模块里[git_branch] symbol branch:这样就不依赖 Nerd Font 字体但视觉上会朴素一些。我个人还是建议装字体毕竟 Starship 默认的视觉风格也是它的一大卖点。6.2 大型 git 仓库里提示符变慢的真相切到 Starship 之后绝大多数场景都是秒开。但有一种情况你早晚会遇到在一个超大 monorepo 里提示符上的 git 分支和状态信息“偶尔不出来”或者“等了半天才出来”。这背后的原理前面第 3 章已经提过Starship 的子进程要执行git status之类的命令收集状态而这类命令在超大仓库里本身可能要几百毫秒甚至更久。如果超过command_timeout默认的 500msStarship 直接放弃显示这个模块于是你的提示符看起来就是“少了点什么”但你输入命令不会阻塞。怎么处理我给出的建议是分层决策如果你觉得少了 git 状态提示很不习惯可以把超时时间稍微调大一点比如 600ms 或 800ms。这里有一个权衡超时时间越大极端情况下提示符渲染等待的时间就越长超时时间越小信息完整度就越差。我自己通常不会超过 1000ms因为一旦超过这个值等待体验就差回去了。如果你对 monorepo 里的 git 状态没那么高的实时要求只想知道当前在哪个分支更推荐的做法是只保留[git_branch]关掉[git_status][git_branch] symbol [git_status] disabled true[git_status]是那个需要额外执行git status --porcelain之类命令、用来展示未提交文件增删改状态的模块它才是大仓库里开销的大头。分支名用git branch --show-current一类相对轻量的命令也能拿到影响小很多。如果你的仓库实在巨大连分支获取都觉得影响体验那还可以彻底关掉 git 相关模块只用[directory]的路径显示。很多人觉得提示符没分支不能忍但我见过不少工程团队终端里根本不显示任何 git 状态他们的理由是状态信息开着反而干扰真正要看状态的时候敲git status就够了。合不合理因人而异适合你的工作流就是好的。6.3 一套能直接用的生产配置这里给出一份我目前经常用的~/.config/starship.toml不算复杂但已经覆盖了大部分日常使用场景你可以在它的基础上改# 新命令和上一个输出之间留一行空行 add_newline true # 子进程抓取信息的超时时间单位毫秒 # 默认是 500大仓库里想让 git 状态更完整可以调到 600-800 command_timeout 600 [character] success_symbol [❯](bold green) error_symbol [❯](bold red) [directory] truncation_length 3 truncate_to_repo true [git_branch] symbol [git_status] ahead ⇡ behind ⇣ untracked ? [nodejs] format [$symbol$version ]($style) [python] format [$symbol$version ]($style) [cmd_duration] min_time 2000 show_milliseconds true format took [$duration]($style) 几个配置项说明一下truncate_to_repo true进入 git 仓库后路径只显示从仓库根到当前目录的部分避免很长一串绝对路径占满终端[cmd_duration]的min_time 2000只有命令执行超过 2 秒才显示耗时避免每个命令后面都跟着一个时间戳视觉噪音太大[nodejs]和[python]的format只保留了符号和版本号去掉了默认的前缀文字和括号更简洁如果你用 Starship 来替代的不只是 zsh 的提示符还包括 IDE 内置终端里的 shell这套配置在 bash 和 zsh 里的表现是一致的拷过去就能用。6.4 配置同步、升级与维护Starship 的配置本质上是纯文本非常适合放进 dotfiles 仓库。我现在是把~/.config/starship.toml软链接到 dotfiles 目录里管理换新机器时克隆仓库再跑一个安装命令提示符就完全就位了。升级方面取决于你当初怎么装的。brew 装的就用brew upgrade starshipWindows 上用 winget 的就用winget upgrade --id Starship.Starship官方脚本装的重跑一次安装脚本就能更新到最新版。Starship 的更新频率不算低偶尔会加新模块或调默认行为升级之后用starship print-config看一眼当前生效配置基本就能发现问题。遇到配置问题或者 bug 时可以先跑starship bug-report这个命令会收集你的系统信息、Shell 版本、Starship 版本和当前配置然后生成一段文本你把它贴到 GitHub issue 或者社区提问里能省很多来回沟通的时间。另外补充一个排查思路如果你觉得某个模块“该显示却没显示”优先怀疑两个原因一个是当前目录不符合模块激活条件比如没有相应文件另一个是子进程超时被丢弃。前者改配置后者调command_timeout或者关掉模块思路清晰了就不会瞎折腾。最后再分享一点个人体会。我现在在家里电脑、公司 Mac 和远程服务器上跑的是同一个starship.toml启动时间基本稳定在 60ms 到 100ms 的范围。虽然我不敢说这个数字是“最快的”但它是混合了功能、颜值、维护成本之后我个人最满意的平衡点。如果你之前一直用 Oh My Zsh 只是因为主题和插件省事我建议你别一步到位删掉它——先把主题关掉、换上 Starship 跑一周习惯了之后再把插件一个个拆出去。这样既不会断崖式失去功能也能慢慢看清哪些插件才是你真正离不开的。启动时间这种东西用起来不觉得一旦优化完再回到旧环境你就再也受不了那个一秒的等待了。 用Starship替换Oh My Zsh主题：终端启动从1秒优化到几十毫秒
如果你的终端也和我之前一样每次新开一个窗口总要等上半秒到一秒提示符才慢悠悠地出现那你大概率装着 Oh My Zsh而且插件越装越多主题也从 default 一路换到了什么都想显示的全能型主题。我以前也是标准的 OMZ 重度用户插件装了二十多个主题用 powerlevel10k.zshrc里塞满了 export、alias、source以及在各种教程里抄来的片段。换来的是启动耗时经常接近一秒进到稍微大一点的 Git 仓库时cd进去还要再等一轮提示符才肯出来。后来我花了一个周末把主题部分切到 Starship顺带做了一点减法启动时间从接近一秒降到几十毫秒这个改动是我近几年在终端体验上性价比最高的一次。下面这篇文章会把我这次折腾的完整过程写清楚它到底替换的是 Oh My Zsh 的哪一层、怎么装、怎么配置、实测能快多少、有哪些坑要先避开。适合所有正在用 OMZ 但觉得启动越来越慢的人也适合刚听说 Starship、想搞清楚它和 OMZ 是什么关系的人。1. 开个终端要等一秒你受得了吗先说说那个让人抓狂的场景。我习惯开一堆终端窗口一个跑本地服务一个连公司跳板机一个随手写点临时命令。以前每次打开新窗口先看到光标在左上角闪几下那段时间终端其实是“静默”的你敲什么它都不反应要等提示符真正跳出来才能输入。如果是在 tmux 里开新窗格或者在 IDE 里拉起一个内置终端这个延迟会被放大得更明显因为整个环境冷启动没什么可缓存的。有的朋友可能觉得几百毫秒而已至于吗但开发时人的注意力是很脆弱的。你脑子里想的是“下一步敲什么命令”结果指尖已经按下去了终端却没响应那种割裂感比慢本身更伤人。尤其是需要频繁开终端的场景比如跑测试、开日志、起 Docker、切环境一天下来“等待终端就绪”的时间累积起来很可观。我那时候的配置大概是这样的Oh My Zsh 主体二十个左右插件包括 git、docker、kubectl、brew、zsh-syntax-highlighting、zsh-autosuggestions、extract、sudo 等等主题是 powerlevel10k开了信息量很大的配置git 分支、git 状态、Python 虚拟环境、Node 版本、命令耗时全都显示还装了 nvm官方安装脚本自动往.zshrc里塞了一段加载逻辑这套组合在新款 MacBook 上启动一次交互式 zsh稳定在 700ms 到 1000ms 之间。进一个大一点的 monorepo第一次渲染提示符还能再让你等个几百毫秒。后来我去了一台弱一点的 Linux 服务器上测试直接奔着 1.2s 去了。说实话这个数字在很多“终端性能优化”文章里都算正常水平但正常不代表合理。一个 shell 而已凭什么要加载这么久才能在光标前画出一个❯Startship 解决的就是这个问题。它不修改你的插件框架也不帮你管理别名和环境变量它只管一件事用足够快的速度把提示符渲染出来。因为它是用 Rust 写的单二进制程序渲染 prompt 的逻辑全部独立在 shell 进程之外还带了子进程超时保护所以最坏情况也就是某个模块超时丢掉不显示而不是整个终端卡在那等。在动手换之前我建议你先做一件事量化自己的启动耗时。这是整个优化的基础。2. 为什么 Oh My Zsh 越用越慢插件、主题与版本管理的叠加效应2.1 先量化你的启动耗时别靠“感觉”不要凭感觉说“我的终端挺快的”或者“我的终端好慢”先跑一个命令把数据拿出来。# 重新开一个终端窗口然后执行 /usr/bin/time -p zsh -i -c exit输出里real那一列就是这次启动的墙钟时间。-i表示以交互模式启动这样.zshrc才会被加载-c exit的意思是启动后立刻退出只测启动过程本身不掺杂后续命令的执行时间。建议跑 5 次取中位数因为第一次冷启动会受磁盘缓存影响通常比后面几次慢。我那时候跑出来的结果中位数是 0.85s 左右看实数据比看“感觉”直观多了。你测出来如果超过 300ms就值得往下看如果只有 50ms那其实没必要折腾你的配置已经很克制了。2.2 插件的加载方式决定了它的天花板Oh My Zsh 的启动流程说复杂不复杂。你的.zshrc里有一行source $ZSH/oh-my-zsh.shOMZ 会做这几件事加载lib目录下的一堆基础函数文件比如 git、clipboard、history、theme 等模块的辅助函数加载你指定的主题脚本遍历plugins(...)数组里声明的插件把每个插件目录下的*.zsh文件按顺序source一遍问题就出在第三步。插件越多被 source 的 shell 脚本就越多而且这些脚本不能并行加载只能一个个来。很多插件又不是几行别名那么简单zsh-syntax-highlighting要在启动时注册 zle 的钩子把输入框里的命令变成颜色高亮这需要初始化一套规则和事件zsh-autosuggestions要初始化补全引擎和词库加载量也不小docker、kubectl、brew这类插件虽然本身逻辑不多但它们引入的补全函数一个比一个大叠加起来启动时间从几十毫秒跳到几百毫秒是非常正常的。关键是这些插件里的很多东西你只是“装着而已”真正用到的可能只有一小部分。比如我为docker-compose装的补全一个月也用不了几次但每次开终端都要白白加载一遍。2.3 真正的“大头”往往不是 OMZ 本身如果你测出来启动非常慢先别急着把所有责任都推给 Oh My Zsh有几个常见的“隐形杀手”往往比 OMZ 本身更占时间。第一个是 nvm。它的官方安装方式会在你的.zshrc里塞一段export NVM_DIR... [ -s $NVM_DIR/nvm.sh ] . $NVM_DIR/nvm.sh意思是每次新开终端都要完整执行一遍nvm.sh而nvm.sh内部会扫描你安装的所有 node 版本目录解析路径、设置别名。版本装多了之后非常拖时间我实测过光是 nvm 这一项就能吃掉 200-400ms。第二个是 pyenv、conda、fvm 这类环境管理工具的初始化脚本。它们的原理都差不多在交互式 shell 启动时执行一段比较重的初始化如果你同时装了 pyenv 和 conda叠加效果更明显。第三个是主题。OMZ 默认主题还好普通机器上也就几十毫秒。但如果你的主题是 powerlevel10k 或者类似的信息密集型主题那每次提示符渲染时都要去同步获取 git 分支、git 状态、远程领先落后多少个提交、当前 Python 虚拟环境名字、上一次命令执行耗时……这些信息大多来自git status、git rev-parse这种命令在小型仓库里还好在几百 MB 的 monorepo 里同步执行一次很容易超过几百毫秒。p10k 其实已经对这个做了很多优化还提供了 instant prompt 这种缓存方案但它的 instant prompt 有使用限制本质上是在“绕过”不是从根上减小开销。而且主题本身这么多信息在一个提示符里视觉上也未必是好事。还有一个很多人没注意到的点如果你用了 zplug、antigen 这类插件管理器它们默认可能会在每次启动时检查插件更新去访问 GitHub 或对应仓库网络一旦慢启动时间直接被拖上天。所以总结下来OMZ 慢不是单一原因是“插件数量 重型环境初始化 主题渲染”三层叠加的结果。你想优化就是把这三层都按到合理水平——Starship 恰好对“主题渲染”这一层做了专门优化。3. 动手前先搞懂Starship 和 Oh My Zsh 的边界在哪里3.1 Starship 只解决“提示符”这一件事Starship 官方对自己的定位叫 “cross-shell prompt”翻译过来就是跨 shell 的提示符引擎。它不是一个 zsh 配置管理框架不碰你的别名不管理插件不设置 PATH 环境变量。它只负责在你敲命令之前把那一行提示符画出来。Oh My Zsh 则是一个 zsh 专属的配置框架覆盖了插件加载、主题、别名、更新机制等多个方面。这两个东西真正重叠的部分只有一个主题也就是提示符的最终呈现。明白这一点很重要因为很多人装完 Starship 以后以为可以整个卸载 OMZ 了结果发现自己的git别名、各种插件补全全部没了一脸懵。更准确的说法是Starship 是 Oh My Zsh 的“主题层”替代品不是整个 OMZ 的替代品。如果你的需求是从一大堆主题配置里解放出来同时保留 OMZ 帮你管理的插件那“继续留着 OMZ只把主题交给 Starship”是完全可行的操作。如果你想要极简启动、连 OMZ 本身都不想加载那需要另外解决插件问题我下面会给出方案。3.2 Starship 快的原理并行子进程与强制超时Starship 快不是玄学底层逻辑很清晰。第一它是用 Rust 写的单二进制文件启动一个进程的代价比执行上百行的 shell 脚本小得多。第二它在每次渲染提示符时会并行启动一些子进程去收集环境信息比如当前 git 仓库的状态、当前目录下的编程语言版本、是否需要显示某些模块。这些子进程和 shell 主进程是隔离的shell 不会被它们里头的某条慢命令彻底阻塞。第三也是最关键的它有强制超时机制。Starship 里有一个顶层配置command_timeout默认 500ms。任何模块的子进程如果在这个时间内没有返回结果就直接放弃显示该模块绝不会无限期等下去。这就是为什么在特别大的 git 仓库里Starship 即使拿不到状态提示符也能很快出现——它选择不展示而不是死等。传统主题做不到这一点因为它们是直接在 shell 进程里同步执行git status的仓库大一点就只能陪着等。第四Starship 的模块是“按需激活”的。比如[nodejs]模块只有当当前目录里有package.json、node_modules或者.js文件时才被激活[git_commit]模块只有当你显式开启了才会去查询 commit 信息。目录里什么都没有时大部分模块根本不启动开销自然低。3.3 迁移前想清楚职能分配所以你在动手之前先想清楚自己属于哪种情况情况处理方式只用 OMZ 的主题功能插件基本不用直接把主题停掉装 Starship最干净主题和插件都在用但插件离不开保留 OMZ 的插件管理只关掉或降级主题让 Starship 接管提示符想从根上减少每次启动的加载量把 OMZ 整个拿掉插件逐个换成单独安装的轻量方案Starship 做提示符有跨 shell 或者多机一致性的需求Starship 的配置是同一个 toml 文件bash、zsh、fish、PowerShell 通用最后一种情况很多人容易忽略。Starship 在 macOS、Linux、Windows 下的提示符渲染逻辑完全一样你只需要同步一个配置文件不需要像 OMZ 那样分别维护 zsh 和 bash 的主题语法。我自己就是被这个跨 shell 一致性打动才决定把它当成长期方案的。4. 迁移实录安装 Starship、替换主题并保住插件4.1 安装与验证先装本体不同平台命令不一样# macOS brew install starship # Linux / WSL也可以直接用官方脚本 curl -sS https://starship.rs/install.sh | sh # Windows winget install --id Starship.Starship # 或者配置过 scoop 的人可以用 # scoop install starship装完先确认一下starship --version能打印出版本号就说明装好了。注意官方安装脚本默认装到/usr/local/bin如果提示没有权限可以加--force加上自定义参数重新执行或者直接用 brew / 发行版包管理器安装省心一些。4.2.zshrc改造关掉重型主题并启动 Starship先备份一份你的.zshrc这个动作在任何配置修改前都值得做cp ~/.zshrc ~/.zshrc.bak然后编辑~/.zshrc。如果你是 p10k 用户第一件事是把 p10k 的初始化注释掉。常见的 p10k 初始化长这样# source /usr/local/share/powerlevel10k/powerlevel10k.zsh-theme # [[ ! -f ~/.p10k.zsh ]] || source ~/.p10k.zsh注释掉之后再把 OMZ 的主题设置改一下。这里有一个很多人容易踩的细节OMZ 在ZSH_THEME为空字符串时会自动回退到 robbyrussell所以别指望设成空字符串来“禁用主题”。你可以直接保留默认主题反正 Starship 会在后续步骤接管提示符多加载一个几十行的默认主题脚本影响很小。# 如果你之前设置了 powerlevel10k注释掉上面那两行 # 然后这里保留默认主题即可Starship 最终会覆盖显示 ZSH_THEMErobbyrussell最后在.zshrc文件末尾追加eval $(starship init zsh)为什么放在最后一个朴素但有效的理由.zshrc里的设置遵循“后加载覆盖先加载”的直觉把 Starship 初始化放在最后能最大程度避免后面某个脚本或者别名把它的 preexec / precmd 钩子或者PROMPT覆盖掉。如果你以后又加了其他自定义 prompt 配置也尽量保持这个顺序。保存后重新开一个终端窗口验证。你应该能看到提示符已经变成默认的 Starship 风格一行带 git 分支路径后面的箭头符号是❯。如果没变化先检查.zshrc里是不是还有别的地方 source 了其他主题或 prompt 初始化脚本。4.3 最简配置先跑起来再谈美化Starship 默认配置已经能用了不需要写任何配置文件。我第一次跑起来的时候提示符会显示当前目录长路径自动截断git 分支名如果目录里检测到 package.json显示当前 Node 版本如果检测到 Git 工作区有未提交状态显示对应的符号这些信息的渲染速度我体感几乎和裸 shell 一样。如果想让提示符更符合自己的习惯可以创建配置文件# ~/.config/starship.toml add_newline true [character] success_symbol [❯](bold green) error_symbol [❯](bold red) [git_branch] symbol 这几行配置的含义是命令成功后提示符是绿色高亮的❯失败变成红色git 分支前显示一个空符号省掉默认的图标。配置写好之后不需要重启终端只要新开一个终端窗口就会自动加载。如果没有生效用下面命令看看当前实际生效的配置starship print-config想直接打开配置文件编辑比较新的 Starship 版本支持starship config它会用你的系统编辑器打开~/.config/starship.toml不存在时会自动创建。4.4 把 OMZ 也卸掉保留高亮和自动补全的轻量方案如果你走完上面几步之后还想进一步降低启动时间可以考虑把 Oh My Zsh 整个拿掉。毕竟 OMZ 的主框架本身也有底噪虽然它没主题那么重但和裸 zsh 比起来还是有差距。卸载其实就是把.zshrc里的source $ZSH/oh-my-zsh.sh注释或删掉。但直接删会带走你所有插件所以先从最离不开的两个插件开始补回来语法高亮和自动补全。这两个是很多 OMZ 用户最常用的插件也是完全独立于 OMZ 的可以单独 clone 下来 sourcemkdir -p ~/.zsh/plugins git clone https://github.com/zsh-users/zsh-autosuggestions ~/.zsh/plugins/zsh-autosuggestions git clone https://github.com/zsh-users/zsh-syntax-highlighting ~/.zsh/plugins/zsh-syntax-highlighting然后在.zshrc里去掉 OMZ 加载行加上source ~/.zsh/plugins/zsh-autosuggestions/zsh-autosuggestions.zsh source ~/.zsh/plugins/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh这里有一个非常关键的顺序zsh-syntax-highlighting一定要放在.zshrc的最后面加载。因为它会重新绑定 zle 的某些回路如果后面还有其他脚本很容易把它的高亮规则或者之前定义的快捷键覆盖掉。这个坑我当初也踩过症状就是自动补全还能用但高亮时有时无。其他需要的插件比如git别名、kubectl补全之类可以根据自己的情况去对应项目仓库单独 clone然后逐个 source。别名和 PATH 就自己在.zshrc里按需写一开始可能不太习惯但慢慢会发现自己的配置干净了很多启动速度和 unicorn 一样轻盈。去掉 OMZ 之后加上 Starship 的完整.zshrc风格大概就是这样export PATH$HOME/.local/bin:$PATH source ~/.zsh/plugins/zsh-autosuggestions/zsh-autosuggestions.zsh source ~/.zsh/plugins/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh eval $(starship init zsh)整个文件也就十几行每个配置是什么用途一目了然。5. 数字说话加速前后的启动耗时对比5.1 测试方法与我所用的组合为了让你对提升幅度有个更直观的认知我把常见几种配置组合放到同一台 Linux 云主机上做了个简单的基准测试。测试方法就是第一节写的/usr/bin/time -p zsh -i -c exit每种组合跑 5 次取中位数。需要注意一个前提测的这台机器是个干净的 2C4G 云服务器网络还算稳定磁盘是 SSD 但性能一般大致相当于一个“不拖后腿但也谈不上高性能”的普通开发环境。我对比了这几组裸 zsh没有任何配置OMZ 默认配置 几个常用插件OMZ 20 个插件 powerlevel10k 信息主题OMZ 保留插件管理但主题降级为默认叠加上 Starship去掉 OMZ只保留 zsh-syntax-highlighting 和 zsh-autosuggestions再加上 Starship去掉 OMZ无插件只有 Starship5.2 结果对比与解读被测组合启动耗时中位数裸 zsh20-40msOMZ 几个常用插件150-300msOMZ 20 插件 powerlevel10k700-1200msOMZ关主题 Starship100-200ms无 OMZ 高亮/补全插件 Starship60-110ms无 OMZ 无插件 Starship30-50ms这个表格里的数值会因为你机器的 CPU、磁盘、具体插件版本而波动但量级关系是稳定的。有两个结论值得强调第一最大的收益来自“放弃重型主题 减少插件加载”这两个动作的叠加而不是 Starship 单点魔法。用 p10k 时 700-1200ms换到 OMZ 默认主题就已经少了一大截再切到 Starship 又进一步。第二就算你完全保留 OMZ 框架只把主题层切到 Starship从 700ms 降到 100-200ms 也已经是体感上“从明显卡顿到接近秒开”的跨越。如果你不想动插件结构这个方案收益已经很可观。5.3 为什么多次测量会有波动你可能自己回去测的时候发现数值和我们表格里的不太一样甚至每次跑出来都不一样。这很正常和下面几个因素有关磁盘缓存第一次冷启动会把相关脚本和二进制读入内存后续再测会快很多所以总强调取中位数而不是第一次nvm / pyenv 的安装脚本位置它们每次启动都要重新解析目录如果配置的网络路径较慢时间波动很大终端模拟器的渲染开销gnome-terminal、iTerm2、Windows Terminal 的字体和样式渲染方式不同会影响你主观感受Starship 的异步特性它的模块信息是子进程并行收集的单次偶尔会因为系统负载多几十毫秒但一般不会超过超时阈值所以看数据的时候不要纠结“到底是 62ms 还是 85ms”而是要问自己这个延迟在可接受范围内吗从接近一秒降到几十毫秒带来的体验提升是跨档次的。还有一个反直觉的地方Starship 每次渲染提示符并不是零开销的它也要启动一个 Rust 进程去收集信息。但因为子进程模式 超时保护它的开销通常只有几十毫秒而且不会出现“卡着不动”的局面。相比之下p10k 在仓库大时是真的会停在那里等 git 命令回来的。6. 进阶调优自定义配置、字体图标与大型仓库卡顿6.1 图标变方块先换字体装完 Starship 第一次打开你可能会发现提示符里有些字符变成方块或者问号尤其是 git 分支和语言版本前面的小图标。这不是 Starship 坏了而是你的终端字体里没有包含 Nerd Font 的特殊字符。Starship 的默认提示符和模块图标大量使用 Nerd Font 符号而 macOS 自带的 Menlo、Linux 常见的 Monospace 字体都不带这些 glyph。解决方案有两个方案一也是推荐方案安装一个 Nerd Font 字体然后在终端设置里把字体切过去。常见的推荐有 FiraCode Nerd Font、JetBrainsMono Nerd Font、MesloLGS Nerd Font。macOS 上可以用 Homebrew 搜索相关包来装比如brew install --cask font-meslo-lg-nerd-font装完之后iTerm2Preferences - Profiles - Text - Font选择对应的 Nerd FontWindows Terminal设置 - 配置文件 - 外观 - 字体GNOME Terminal偏好设置 - 配置文件 - 自定义字体方案二不想折腾字体的话把模块的 symbol 都换成普通 ASCII 字符能接受就接受。比如在[git_branch]模块里[git_branch] symbol branch:这样就不依赖 Nerd Font 字体但视觉上会朴素一些。我个人还是建议装字体毕竟 Starship 默认的视觉风格也是它的一大卖点。6.2 大型 git 仓库里提示符变慢的真相切到 Starship 之后绝大多数场景都是秒开。但有一种情况你早晚会遇到在一个超大 monorepo 里提示符上的 git 分支和状态信息“偶尔不出来”或者“等了半天才出来”。这背后的原理前面第 3 章已经提过Starship 的子进程要执行git status之类的命令收集状态而这类命令在超大仓库里本身可能要几百毫秒甚至更久。如果超过command_timeout默认的 500msStarship 直接放弃显示这个模块于是你的提示符看起来就是“少了点什么”但你输入命令不会阻塞。怎么处理我给出的建议是分层决策如果你觉得少了 git 状态提示很不习惯可以把超时时间稍微调大一点比如 600ms 或 800ms。这里有一个权衡超时时间越大极端情况下提示符渲染等待的时间就越长超时时间越小信息完整度就越差。我自己通常不会超过 1000ms因为一旦超过这个值等待体验就差回去了。如果你对 monorepo 里的 git 状态没那么高的实时要求只想知道当前在哪个分支更推荐的做法是只保留[git_branch]关掉[git_status][git_branch] symbol [git_status] disabled true[git_status]是那个需要额外执行git status --porcelain之类命令、用来展示未提交文件增删改状态的模块它才是大仓库里开销的大头。分支名用git branch --show-current一类相对轻量的命令也能拿到影响小很多。如果你的仓库实在巨大连分支获取都觉得影响体验那还可以彻底关掉 git 相关模块只用[directory]的路径显示。很多人觉得提示符没分支不能忍但我见过不少工程团队终端里根本不显示任何 git 状态他们的理由是状态信息开着反而干扰真正要看状态的时候敲git status就够了。合不合理因人而异适合你的工作流就是好的。6.3 一套能直接用的生产配置这里给出一份我目前经常用的~/.config/starship.toml不算复杂但已经覆盖了大部分日常使用场景你可以在它的基础上改# 新命令和上一个输出之间留一行空行 add_newline true # 子进程抓取信息的超时时间单位毫秒 # 默认是 500大仓库里想让 git 状态更完整可以调到 600-800 command_timeout 600 [character] success_symbol [❯](bold green) error_symbol [❯](bold red) [directory] truncation_length 3 truncate_to_repo true [git_branch] symbol [git_status] ahead ⇡ behind ⇣ untracked ? [nodejs] format [$symbol$version ]($style) [python] format [$symbol$version ]($style) [cmd_duration] min_time 2000 show_milliseconds true format took [$duration]($style) 几个配置项说明一下truncate_to_repo true进入 git 仓库后路径只显示从仓库根到当前目录的部分避免很长一串绝对路径占满终端[cmd_duration]的min_time 2000只有命令执行超过 2 秒才显示耗时避免每个命令后面都跟着一个时间戳视觉噪音太大[nodejs]和[python]的format只保留了符号和版本号去掉了默认的前缀文字和括号更简洁如果你用 Starship 来替代的不只是 zsh 的提示符还包括 IDE 内置终端里的 shell这套配置在 bash 和 zsh 里的表现是一致的拷过去就能用。6.4 配置同步、升级与维护Starship 的配置本质上是纯文本非常适合放进 dotfiles 仓库。我现在是把~/.config/starship.toml软链接到 dotfiles 目录里管理换新机器时克隆仓库再跑一个安装命令提示符就完全就位了。升级方面取决于你当初怎么装的。brew 装的就用brew upgrade starshipWindows 上用 winget 的就用winget upgrade --id Starship.Starship官方脚本装的重跑一次安装脚本就能更新到最新版。Starship 的更新频率不算低偶尔会加新模块或调默认行为升级之后用starship print-config看一眼当前生效配置基本就能发现问题。遇到配置问题或者 bug 时可以先跑starship bug-report这个命令会收集你的系统信息、Shell 版本、Starship 版本和当前配置然后生成一段文本你把它贴到 GitHub issue 或者社区提问里能省很多来回沟通的时间。另外补充一个排查思路如果你觉得某个模块“该显示却没显示”优先怀疑两个原因一个是当前目录不符合模块激活条件比如没有相应文件另一个是子进程超时被丢弃。前者改配置后者调command_timeout或者关掉模块思路清晰了就不会瞎折腾。最后再分享一点个人体会。我现在在家里电脑、公司 Mac 和远程服务器上跑的是同一个starship.toml启动时间基本稳定在 60ms 到 100ms 的范围。虽然我不敢说这个数字是“最快的”但它是混合了功能、颜值、维护成本之后我个人最满意的平衡点。如果你之前一直用 Oh My Zsh 只是因为主题和插件省事我建议你别一步到位删掉它——先把主题关掉、换上 Starship 跑一周习惯了之后再把插件一个个拆出去。这样既不会断崖式失去功能也能慢慢看清哪些插件才是你真正离不开的。启动时间这种东西用起来不觉得一旦优化完再回到旧环境你就再也受不了那个一秒的等待了。