很多人第一次装 zsh流程都差不多包管理器装一下、chsh改默认 shell、再顺手拉一个插件框架打开终端看见提示符变了颜色、多了个分支名就觉得这事儿办完了。我自己也这么干过用了小半年才发现真正让 zsh 和 bash 拉开差距的东西我一个都没碰——补全还是bash那套 bash-completion历史记录还是各窗口各管各的启动还慢了两百多毫秒。zsh 这个命令本身没什么神秘的它就是一个交互式 shell但它的价值几乎全部藏在“配置”和“补全”这两件事里光装上不配体验甚至不如默认的 bash。这篇东西写给两类人一类是刚把 zsh 设成默认 shell、还在到处抄zshrc的朋友另一类是已经用了一阵但总觉得“好像也就那样”、不确定自己是不是漏了什么的人。下面我会把 zsh 的配置文件加载顺序、补全机制、插件框架取舍、提示符设计、启动性能这几块拆开讲每一块都配上我自己实际在用的配置片段和踩过的坑。所有配置都在普通用户权限下能跑通不需要特殊环境。1. zsh 装完之后“没感觉”的几个真实原因1.1 交互式 shell 和脚本 shell 本来就是两套需求先把定位说清楚不然很容易走偏。bash 的定位是“到处都有、POSIX 兼容性好、写脚本稳”zsh 的定位更偏向“人机交互舒服”。这两件事的评价标准完全不同脚本关心的是可移植性和确定的行为交互关心的是补全准不准、提示信息全不全、按键响应快不快。所以我的实际做法是两条线分开日常登录终端用 zsh但所有要提交到仓库、要在别人机器上跑的脚本一律写#!/usr/bin/env bash或者#!/bin/sh绝不写成 zsh。原因在最后一节会详细说简单讲就是 zsh 默认的一些展开行为、数组下标起点、词分割规则跟 POSIX 不一样一个在 zsh 里跑得好好的脚本换到别的环境里可能直接炸。提示判断某个 shell 特性能不能用在脚本里最简单的办法是把脚本头部改成#!/bin/sh再跑一遍跑不通就说明你依赖了 bash 或 zsh 的扩展特性。1.2 三个最常见的原因没有配置文件、补全没初始化、习惯没迁移装完没感觉八成是这三个原因之一。第一~/.zshrc根本不存在或者是个空文件。很多发行版的 zsh 包只装二进制不给你放默认配置你打开就是一套极其朴素的提示符连命令行编辑的按键绑定都是最原始的。第二补全系统没有初始化。zsh 的补全不是“默认开着”的需要显式加载compinit。没这一步你按 Tab 得到的行为非常有限很多人就是在这一步觉得“zsh 补全还不如 bash”。第三历史命令、别名、常用函数没搬过来。你原来在 bash 里攒了两千条历史记录、几十个别名切过来之后这些全空了肌肉记忆全部失效体感当然是变差了。历史记录是可以迁移的下文会给出做法。1.3 什么情况下其实不该切不是所有人都适合切。我见过几种情况切过去纯属给自己找麻烦。一是工作环境里有大量需要严格遵守规范的构建脚本团队统一用 bash你本地用 zsh 调试容易调出“我这儿能跑”的幻觉。二是机器资源极其紧张zsh 加上一堆插件的内存占用和启动开销确实比裸 bash 高虽然现在这点差距在普通开发机上可以忽略。三是你只是偶尔登一次服务器敲两条命令那真没必要折腾bash加个bash-completion足够。判断标准其实很简单你在终端里待的时间是不是足够长长到值得花两个小时配一次。够长就配不够长就先放着。下面这张表是我自己总结的取舍依据供参考。场景建议理由每天终端使用超过 2 小时切并认真配补全和历史的收益会持续兑现只在部署时登服务器不切配置成本摊不回来需要维护大量 shell 脚本交互用 zsh脚本用 bash两者职责分开最省心多人共用的跳板机不切或只改自己的 rc别动全局默认 shell2. 五个配置文件的加载顺序决定了你 90% 的怪问题2.1 每个文件什么时候被读到这是我觉得最该先弄明白的一块因为后面所有的“为什么我的环境变量在某些窗口里没有”“为什么 SSH 进来和本地打开的终端行为不一样”根子都在这个加载顺序上。zsh 的启动文件不是一个是五个而且分登录 shell、交互 shell 两种维度。登录 shell 指的是需要走完整登录流程的会话比如 SSH 连进来、或者su -、或者某些终端模拟器在特定设置下启动的会话交互 shell 指的是不需要登录、但需要接受键盘输入的会话比如你在已有的终端里再敲一个zsh。文件触发条件典型用途~/.zshenv所有启动类型永远最先读全局环境变量、PATH 基础设置~/.zprofile登录 shell一次性初始化类似 bash 的 profile~/.zshrc交互 shell别名、补全、提示符、插件写最多的就是这个~/.zlogin登录 shell在 zshrc 之后需要依赖交互配置的登录后动作~/.zlogout登录 shell 退出时清理临时文件、记录退出时间加载顺序就是上面表格从上到下zshenv→zprofile→zshrc→zlogin。注意一个细节登录 shell 会先读zshenv再读zprofile然后读zshrc最后读zlogin。而纯交互非登录 shell 只读zshenv和zshrc。这就是为什么你把 PATH 写在zshrc里某些通过非交互方式启动的进程就找不到命令。2.2 环境变量放在 zshenv交互配置放在 zshrc我自己的分法是zshenv只放两类东西——PATH 和那些需要被子进程继承的全局变量比如EDITOR、LANG、各类工具的配置目录其他一概放zshrc。这样做的好处很实在。你把一大坨别名、补全、插件全塞进zshenv那每次任何非交互的 zsh 调用比如某个程序内部exec zsh -c都要跑一遍白白拖慢速度。反过来把 PATH 只写在zshrc里某些不经过交互 shell 的启动路径就拿不到正确的 PATH。一个简单的zshenv示例我自己的版本大概长这样# ~/.zshenv # 只在 PATH 未包含时追加避免重复嵌套 typeset -U path path( $HOME/.local/bin $HOME/bin $path ) export PATH export EDITORvim export LANGen_US.UTF-8 export PAGERless里面那个typeset -U path是关键。-U表示去重zsh 会保证path数组里没有重复项。因为path数组和PATH变量是绑定的改数组等于改 PATH而-U让你可以放心地在多处重复追加同一个目录。2.3 PATH 越切越长这个坑几乎人人踩过从 bash 迁过来的人最常见的一处翻车是 PATH 里同一个目录出现七八次。原因是老的 bash 配置里用export PATH$PATH:/xxx这种写法迁到 zsh 之后又被别的地方追加了一遍而 zsh 不会自动去重。判断方法很直接echo $PATH | tr : \n | sort | uniq -c | sort -rn | head如果第一行计数大于 1说明有重复。修法就是上面说的typeset -U path配合数组写法追加。这个改动最好放在zshenv的最前面保证后面所有的追加都受益。另一个相关的小坑zsh 里path是数组PATH是字符串两者双向同步。所以你可以写path(/opt/tools/bin)等价于往 PATH 末尾追加。但如果你写export PATH$PATH:/opt/tools/bin那走的是字符串拼接路径这次修改也会同步回数组只是失去了去重保护。两种写法别混用。3. 补全系统才是 zsh 真正的分水岭3.1 compinit 干了什么为什么第一次会卡一下zsh 的补全能力来自compsys这套机制入口就是compinit。它做的主要事情是扫描$fpath下面所有的_*文件这些就是补全函数定义把它们登记成可调用的补全器。第一次运行compinit会明显感觉卡顿因为它在扫描目录。之后 zsh 会在~/.zcompdump里缓存这个索引后续启动就快了。但这里有个坑如果你装了一堆插件、$fpath变了缓存就会失效重新扫描如果不处理你会觉得时快时慢。我用的方式是这样# ~/.zshrc autoload -Uz compinit # 每天最多重建一次补全缓存 if [[ -n ${ZDOTDIR:-$HOME}/.zcompdump(#qN.mh24) ]]; then compinit else compinit -C fi(#qN.mh24)是 zsh 的 glob 限定符语法大意是“匹配存在且修改时间在 24 小时内的文件”。存在就带-C跳过安全检查直接读缓存不存在就完整重建。这一招在机械硬盘或者网络文件系统上收益特别明显。注意-C会跳过补全函数的完整性检查。如果你在多用户机器上且$fpath里有别人可写的目录慎用-C。3.2 几个值得开的小开关compinit之后可以再加几行配置把补全的行为调得更贴合习惯。我常用的几条# 补全菜单第一次 Tab 列出第二次 Tab 进入选择 zstyle :completion:* menu select # 补全候选带颜色和分组描述 zstyle :completion:* list-colors ${(s.:.)LS_COLORS} zstyle :completion:* group-name zstyle :completion:*:descriptions format %F{yellow}-- %d --%f # 大小写不敏感 部分匹配 zstyle :completion:* matcher-list m:{a-z}{A-Za-z} r:|[._-]* r:|* # 近似纠错敲错一个字母也能给建议 zstyle :completion:* completer _complete _correct _approximatematcher-list那行是最值得抄的。改完之后你可以用小写补全大写的路径、用cd /u/lo/bi补到/usr/local/bin。completer里加上_approximate之后命令名敲错一个字母按 Tab它会给你“你是不是想输入 xxx”的候选这个在记不住长命令名的时候非常有用。3.3 给自己的内部脚本写补全这是 zsh 相对 bash 的一个明显优势自定义补全函数写起来结构清晰得多。假设你有一个内部工具叫deployctl支持deployctl [env] [service]两个参数环境只有 dev/staging/prod 三个值。补全函数大概这样写# 放到 $fpath 下任意目录文件名必须叫 _deployctl #compdef deployctl _deployctl() { local -a envs services envs(dev staging prod) services(${(f)$(deployctl list-services 2/dev/null)}) _arguments -C \ 1:environment:(${envs[]}) \ 2:service:(${services[]}) \ *::arg:-args } _deployctl $关键是文件命名必须是下划线加命令名然后用#compdef声明最后把文件所在目录加进fpath再跑一次compinit。相比 bash 的complete -Fzsh 的_arguments把位置参数、可选参数、互斥关系都描述得干干净净可读性高一个档次。我自己维护了一个~/.zsh/completions/目录专门放这些内部工具的补全在zshrc里加一行fpath(~/.zsh/completions $fpath)就够了注意这一行必须在compinit之前。4. 插件框架的取舍全量套用和按需组装差在哪4.1 一把梭的框架和十几个手动 source 文件刚上手的时候几乎所有人都会用现成的插件框架因为一行命令就能把补全、语法高亮、自动建议全部装好。这没什么问题问题出在后面你想要加一个自己写的小函数发现不知道该往哪放你想删一个用不上的插件发现它已经被框架接管了你打开新窗口发现要等半秒因为框架在加载二十多个插件。我用过好几种方案体感上的差异主要在三块启动耗时、配置可读性、出问题时排查难度。方案启动耗时典型上手成本排查难度适合谁现成框架一把梭200-500ms极低较难配置分散刚切换、想快速见效手动 source 各插件50-120ms中等容易一目了然熟悉之后长期维护延迟加载函数触发30-80ms偏高中等需理解触发机制追求极致启动速度我自己现在的做法是中间那条路不用框架zshrc里手动 source 五六个插件全部加起来不到三十行。这样做的最大好处是可读性——任何时候打开zshrc我都能一眼看出这台机器上到底加载了什么出问题直接二分注释就能定位。4.2 延迟加载把不常用的东西推迟到第一次调用有些东西确实不常用但偶尔又需要比如版本管理相关的补全、容器相关的补全。这类插件每次启动都加载一遍是浪费。延迟加载的思路是启动时只定义一层的桩函数真正的加载发生在第一次调用时。# 一个通用的延迟加载小工具 lazy_load() { local func_name$1 plugin_file$2 eval $func_name() { unfunction $func_name source $plugin_file $func_name \\$\ } }原理很简单把同名函数定义成一个“替身”第一次调用时删掉自己、加载真身、再把参数透传过去。这样第一次调用慢一点点但后续所有会话的启动都省下了这段时间。我个人只对少数几个重插件这么做比如一些体积较大的补全定义。对每次都会用到的比如语法高亮延迟加载反而让第一次体验变差不值得。注意延迟加载的插件不能提供“启动时就需要生效”的功能比如修改bindkey或者注册precmd钩子。这类必须启动时加载。4.3 我的最小组合和选择理由如果让我只留四个插件我会选历史搜索比如fzf的 history 集成、语法高亮、自动建议、补全增强。理由分别是历史搜索解决的是“我明明执行过这个长命令但忘了长什么样”按CtrlR模糊搜一把比用箭头翻半天效率高一个量级。语法高亮解决的是“这条命令我会不会在当前目录下执行出错”输入时就能看到红色提示。自动建议把历史里最匹配的一条以灰色显示在光标后按右键接受日常重复性操作能省下大量击键。补全增强就是前面说的那套zstyle加一些额外的_*补全文件。这四样加起来几乎覆盖了所有交互里的高频痛点。剩下的各种花哨功能我试过一轮之后基本都删了——看着好看用一周就无感。5. 提示符设计把哪些信息放进第一行值得算一笔账5.1 PROMPT 里的转义和条件展开zsh 的提示符用PROMPT或PS1定义里面支持一套百分号转义比如%n用户名、%m主机名、%~相对家目录的路径、%F{颜色}开始着色、%f结束着色。最有用的是条件展开%(1j.后台任务.)这种写法只有条件成立时才显示某段内容。# 一个信息密度适中、不花哨的两行提示符 setopt PROMPT_SUBST PROMPT%F{blue}%~%f %(?.%F{green}.%F{red}[%?]%f) RPROMPT%(1j.%F{yellow}[jobs]%f.)%(?.%F{cyan}%D{%H:%M}.%F{red}%D{%H:%M})第一行只放路径和上一条命令的退出码退出码为 0 时不显示非 0 时以红色方括号显示。第二行右提示符放后台任务数和当前时间。这里有个我自己坚持的原则第一行只放“必须马上知道”的信息。路径和退出码属于这一类。用户名和主机名我全部去掉了因为绝大多数时候是本地单机加了只是噪音。如果经常在多台机器之间跳那主机名就必须加不然容易敲错地方。5.2 右提示符的取舍和长命令折叠RPROMPT挺好用但有个很实际的坑当你的命令行特别长、超过了终端宽度右提示符会顶到左边把内容挤乱。解决办法是在RPROMPT里加判断或者在命令太长时自动隐藏# 命令长度超过一定值时隐藏右提示符 RPROMPT%{$(( COLUMNS - ${#${(%):-$PROMPT}} - 20 0 )) echo %F{cyan}%D{%H:%M}%f}这个写法略绕属于能用但不好维护的类型。更清爽的做法是用precmd钩子在每次画提示符前动态设置set_rprompt() { if (( ${#BUFFER} COLUMNS - 20 )); then RPROMPT else RPROMPT%F{cyan}%D{%H:%M}%f fi }配合zle-line-pre-redraw之类的事件可以做到输入过程中实时更新但这一步已经有点过度工程了。我的建议是先用简单的固定右提示符真被挤烦了再上动态方案。5.3 主题别成为启动时间的黑洞现在流行的提示符工具有几个配置现成、开箱好看但要清楚一件事它们会在每次画提示符时执行外部命令去收集信息分支名、版本、状态这些子进程开销会直接体现在每次回车之后的延迟上。判断方法很简单敲一个空回车感觉一下“到下一个提示符出现”之间有没有肉眼可辨的停顿。如果有打开它的配置把用不上的模块全关掉尤其是版本号检测、云环境检测这类每次都要读文件的模块。提示一个粗糙但有效的自测办法是在慢速机器上对比——把提示符主题临时改成PROMPT$ 如果回车响应立刻变快那问题就在主题上不用怀疑别处。6. 启动性能从三百毫秒压到八十毫秒的排查链路6.1 先量别猜打开新终端觉得慢第一反应通常是“肯定是我插件装多了”然后开始瞎删。这个顺序是错的得先量。最直接的方法是用 zsh 自带的zprof# 放在 .zshrc 最顶部 zmodload zsh/zprof # 放在 .zshrc 最底部 zprof下次启动时它会打印一张表按累计耗时排序前几名一目了然。实测下来耗时排名靠前的往往是这几类compinit重建缓存、版本管理工具的初始化脚本、nvm之类的环境加载、还有某些框架的全量插件扫描。第二种方法是给每个配置段打时间戳# .zshrc 顶部 zmodload zsh/datetime typeset -F SECONDS _ts_start$SECONDS # 每段之间插入 _log_ts() { print -rP %F{yellow}[$(( SECONDS - _ts_start ))]%f $1 2 } _log_ts after compinit这种方式适合定位“到底是我自己写的哪一段慢”比zprof更直观。6.2 我实际遇到过的三个元凶第一个是nvm之类的版本管理脚本。它们默认会在启动时做一堆路径拼装和版本检测动辄一百多毫秒。解决办法是延迟加载不加载环境只在真的调用node、npm时再初始化。社区有现成的延迟加载脚本核心思路就是把node定义成函数第一次调用时才 source 真实环境。第二个是compinit每次都完整重建。前面讲过加日期判断和-C就解决了。第三个出乎我意料某些主题脚本里做了git status调用而且是在precmd里每次画提示符都执行一次。在大型仓库里这个调用能到几十毫秒表现就是“在这个项目目录下敲回车特别卡换个目录就好了”。定位方法就是换个空目录试试如果立刻变快那八成是这个问题。6.3 优化前后的对照我把自己的zshrc优化过程记录下来大概是这么个轨迹阶段启动耗时做了什么初始框架全量约 380ms装了框架默认插件全开关掉不用的插件约 210ms只留四五个核心插件补全缓存优化约 140mscompinit -C加日缓存判断延迟加载重量级工具约 95ms版本管理、云工具延迟加载移除主题的外部调用约 80ms提示符改为纯内置转义测量方式统一用time zsh -i -c exit跑五次取中位数避免单次抖动。这个命令的前提是你得在zshrc里没有会阻塞的交互提示否则量出来全是等待时间。7. 那些让人抓头发的报错和排查路径7.1 “can only be called from completion function”这个报错我见过太多次典型场景是在zshrc里直接调用了_arguments或者在某些不该出现的地方用了补全函数。根本原因是补全函数只能在补全上下文里被调用你在普通脚本或者配置里直接调它它拿不到补全环境就报这个。排查思路是往上找调用栈看这个补全函数是被谁触发的。常见的几种误用包括把补全定义文件直接source到zshrc正确做法是放进fpath让compinit去扫描、在补全函数里调用了非补全上下文的外部命令。7.2 “no matches found” 和通配符展开zsh 默认会在通配符匹配不到任何文件时直接报错no matches found而不是像 bash 那样把字面量原样传给命令。这个差异把不少人坑过尤其是用find或者某些命令行工具时写了带方括号的参数。举个例子你想跑grep foo[0-9] file.txt不加引号的话 zsh 试图把它当 glob 展开匹配不到就报错。解决办法有两个给参数加引号推荐或者关掉这个行为# 不推荐全局关闭但可以在特定命令上放开 setopt no_nomatch我自己的做法是保留nomatch它其实能帮你早发现通配符写错只在个别确实需要字面量的场景用引号规避。保持这个严格性是有好处的比如rm *.tmp在当前目录没有 tmp 文件时bash 会把*.tmp原样传给rm然后报文件不存在而 zsh 直接拒绝执行某种意义上更安全。7.3 历史记录不共享、退出后丢失刚切换的时候很容易遇到一个窗口敲的命令另一个窗口按上箭头找不到或者关掉窗口之后历史就没了。原因有两个。一是 zsh 默认的历史文件写入时机和 bash 不同可能需要显式配置。二是多个窗口并发写同一个历史文件时需要加锁。我的配置是HISTFILE~/.zsh_history HISTSIZE50000 SAVEHIST50000 setopt INC_APPEND_HISTORY # 命令执行后立即追加不等退出 setopt SHARE_HISTORY # 多个会话共享同一份历史 setopt HIST_IGNORE_ALL_DUPS # 重复命令只保留一条 setopt HIST_IGNORE_SPACE # 以空格开头的命令不记录 setopt HIST_VERIFY # 从历史调出时不立即执行先给我编辑HIST_IGNORE_SPACE这条特别实用处理敏感参数的命令前面加个空格就不会被写进历史文件。INC_APPEND_HISTORY加上SHARE_HISTORY之后多窗口之间基本不会丢记录了。7.4 别名和函数打架zsh 里函数和别名的优先级、生效时机有些微妙。常见的困惑是“我明明定义了别名为什么脚本里没生效”。原因是别名在非交互 shell 里默认不展开这是有意为之避免脚本被用户环境干扰。另一个常见现象是alias lsls --colorauto之后某些依赖ls原始行为的脚本出问题。绕过办法是在命令前加反斜杠或者command\ls或者command ls会跳过别名。这个方法值得记住排查“是不是别名搞的鬼”时第一件事就是加个反斜杠试试。8. 把 zsh 当脚本解释器用之前先搞清楚这些差异8.1 数组下标从 1 开始这是最容易翻车的一条。bash 的数组第一个元素是${arr[0]}zsh 里是${arr[1]}而${arr[0]}在 zsh 里指向的是整个数组效果类似$。一个从 bash 抄过来的循环在 zsh 里跑出来的结果会整体偏移一位而且不会报错属于最难发现的那类问题。# zsh 里的正确写法 arr(a b c) echo ${arr[1]} # a echo ${arr[0]} # a b c整个数组 echo ${(k)arr} # 1 2 3所有下标8.2 词分割的默认行为不同bash 在展开未加引号的变量时会做词分割vara b; for x in $var会循环两次。zsh 默认不做词分割这个循环只跑一次$var整体作为一个元素。这个差异导致大量 bash 脚本在 zsh 下行为完全变了。反过来zsh 提供了更明确的分割语法${var}显式要求按空白分割或者${(s:,:)var}按逗号分割。用显式语法替代隐式规则脚本意图会更清楚。8.3 需要兼容时用 emulate如果确实有脚本必须同时兼容两种 shell可以在 zsh 脚本开头加一句emulate -L shemulate -L sh会把当前函数的选项和行为切到 sh 兼容模式-L表示只在当前函数作用域内生效不影响调用者。这是比手动逐个setopt更省事的做法也是我推荐写 zsh 脚本时的标准开头。不过说到底我的态度还是需要严格保证可移植性的脚本老老实实写 bash 或 sh只有在确定目标环境就是 zsh 的情况下才用 zsh 的特性去换开发效率。两者别混着来混着来迟早出问题。最后分享一个我自己的小习惯zshrc里所有自定义函数和别名我都用注释分成“每天都用”“偶尔用”“备用别删”三块放在文件最上面。这样每次想清理的时候从最下面那块的末尾往上删就行不用通读全文。这个习惯给我省过好几次误删——有一次差点把一个用了三年的部署函数删掉因为它当时被我归在“偶尔用”那块的最后一个。 
长河君 · 2026/10/28 7:00:45 · 阅读 1.2k zsh 配置与补全实战：从加载顺序到启动性能优化
很多人第一次装 zsh流程都差不多包管理器装一下、chsh改默认 shell、再顺手拉一个插件框架打开终端看见提示符变了颜色、多了个分支名就觉得这事儿办完了。我自己也这么干过用了小半年才发现真正让 zsh 和 bash 拉开差距的东西我一个都没碰——补全还是bash那套 bash-completion历史记录还是各窗口各管各的启动还慢了两百多毫秒。zsh 这个命令本身没什么神秘的它就是一个交互式 shell但它的价值几乎全部藏在“配置”和“补全”这两件事里光装上不配体验甚至不如默认的 bash。这篇东西写给两类人一类是刚把 zsh 设成默认 shell、还在到处抄zshrc的朋友另一类是已经用了一阵但总觉得“好像也就那样”、不确定自己是不是漏了什么的人。下面我会把 zsh 的配置文件加载顺序、补全机制、插件框架取舍、提示符设计、启动性能这几块拆开讲每一块都配上我自己实际在用的配置片段和踩过的坑。所有配置都在普通用户权限下能跑通不需要特殊环境。1. zsh 装完之后“没感觉”的几个真实原因1.1 交互式 shell 和脚本 shell 本来就是两套需求先把定位说清楚不然很容易走偏。bash 的定位是“到处都有、POSIX 兼容性好、写脚本稳”zsh 的定位更偏向“人机交互舒服”。这两件事的评价标准完全不同脚本关心的是可移植性和确定的行为交互关心的是补全准不准、提示信息全不全、按键响应快不快。所以我的实际做法是两条线分开日常登录终端用 zsh但所有要提交到仓库、要在别人机器上跑的脚本一律写#!/usr/bin/env bash或者#!/bin/sh绝不写成 zsh。原因在最后一节会详细说简单讲就是 zsh 默认的一些展开行为、数组下标起点、词分割规则跟 POSIX 不一样一个在 zsh 里跑得好好的脚本换到别的环境里可能直接炸。提示判断某个 shell 特性能不能用在脚本里最简单的办法是把脚本头部改成#!/bin/sh再跑一遍跑不通就说明你依赖了 bash 或 zsh 的扩展特性。1.2 三个最常见的原因没有配置文件、补全没初始化、习惯没迁移装完没感觉八成是这三个原因之一。第一~/.zshrc根本不存在或者是个空文件。很多发行版的 zsh 包只装二进制不给你放默认配置你打开就是一套极其朴素的提示符连命令行编辑的按键绑定都是最原始的。第二补全系统没有初始化。zsh 的补全不是“默认开着”的需要显式加载compinit。没这一步你按 Tab 得到的行为非常有限很多人就是在这一步觉得“zsh 补全还不如 bash”。第三历史命令、别名、常用函数没搬过来。你原来在 bash 里攒了两千条历史记录、几十个别名切过来之后这些全空了肌肉记忆全部失效体感当然是变差了。历史记录是可以迁移的下文会给出做法。1.3 什么情况下其实不该切不是所有人都适合切。我见过几种情况切过去纯属给自己找麻烦。一是工作环境里有大量需要严格遵守规范的构建脚本团队统一用 bash你本地用 zsh 调试容易调出“我这儿能跑”的幻觉。二是机器资源极其紧张zsh 加上一堆插件的内存占用和启动开销确实比裸 bash 高虽然现在这点差距在普通开发机上可以忽略。三是你只是偶尔登一次服务器敲两条命令那真没必要折腾bash加个bash-completion足够。判断标准其实很简单你在终端里待的时间是不是足够长长到值得花两个小时配一次。够长就配不够长就先放着。下面这张表是我自己总结的取舍依据供参考。场景建议理由每天终端使用超过 2 小时切并认真配补全和历史的收益会持续兑现只在部署时登服务器不切配置成本摊不回来需要维护大量 shell 脚本交互用 zsh脚本用 bash两者职责分开最省心多人共用的跳板机不切或只改自己的 rc别动全局默认 shell2. 五个配置文件的加载顺序决定了你 90% 的怪问题2.1 每个文件什么时候被读到这是我觉得最该先弄明白的一块因为后面所有的“为什么我的环境变量在某些窗口里没有”“为什么 SSH 进来和本地打开的终端行为不一样”根子都在这个加载顺序上。zsh 的启动文件不是一个是五个而且分登录 shell、交互 shell 两种维度。登录 shell 指的是需要走完整登录流程的会话比如 SSH 连进来、或者su -、或者某些终端模拟器在特定设置下启动的会话交互 shell 指的是不需要登录、但需要接受键盘输入的会话比如你在已有的终端里再敲一个zsh。文件触发条件典型用途~/.zshenv所有启动类型永远最先读全局环境变量、PATH 基础设置~/.zprofile登录 shell一次性初始化类似 bash 的 profile~/.zshrc交互 shell别名、补全、提示符、插件写最多的就是这个~/.zlogin登录 shell在 zshrc 之后需要依赖交互配置的登录后动作~/.zlogout登录 shell 退出时清理临时文件、记录退出时间加载顺序就是上面表格从上到下zshenv→zprofile→zshrc→zlogin。注意一个细节登录 shell 会先读zshenv再读zprofile然后读zshrc最后读zlogin。而纯交互非登录 shell 只读zshenv和zshrc。这就是为什么你把 PATH 写在zshrc里某些通过非交互方式启动的进程就找不到命令。2.2 环境变量放在 zshenv交互配置放在 zshrc我自己的分法是zshenv只放两类东西——PATH 和那些需要被子进程继承的全局变量比如EDITOR、LANG、各类工具的配置目录其他一概放zshrc。这样做的好处很实在。你把一大坨别名、补全、插件全塞进zshenv那每次任何非交互的 zsh 调用比如某个程序内部exec zsh -c都要跑一遍白白拖慢速度。反过来把 PATH 只写在zshrc里某些不经过交互 shell 的启动路径就拿不到正确的 PATH。一个简单的zshenv示例我自己的版本大概长这样# ~/.zshenv # 只在 PATH 未包含时追加避免重复嵌套 typeset -U path path( $HOME/.local/bin $HOME/bin $path ) export PATH export EDITORvim export LANGen_US.UTF-8 export PAGERless里面那个typeset -U path是关键。-U表示去重zsh 会保证path数组里没有重复项。因为path数组和PATH变量是绑定的改数组等于改 PATH而-U让你可以放心地在多处重复追加同一个目录。2.3 PATH 越切越长这个坑几乎人人踩过从 bash 迁过来的人最常见的一处翻车是 PATH 里同一个目录出现七八次。原因是老的 bash 配置里用export PATH$PATH:/xxx这种写法迁到 zsh 之后又被别的地方追加了一遍而 zsh 不会自动去重。判断方法很直接echo $PATH | tr : \n | sort | uniq -c | sort -rn | head如果第一行计数大于 1说明有重复。修法就是上面说的typeset -U path配合数组写法追加。这个改动最好放在zshenv的最前面保证后面所有的追加都受益。另一个相关的小坑zsh 里path是数组PATH是字符串两者双向同步。所以你可以写path(/opt/tools/bin)等价于往 PATH 末尾追加。但如果你写export PATH$PATH:/opt/tools/bin那走的是字符串拼接路径这次修改也会同步回数组只是失去了去重保护。两种写法别混用。3. 补全系统才是 zsh 真正的分水岭3.1 compinit 干了什么为什么第一次会卡一下zsh 的补全能力来自compsys这套机制入口就是compinit。它做的主要事情是扫描$fpath下面所有的_*文件这些就是补全函数定义把它们登记成可调用的补全器。第一次运行compinit会明显感觉卡顿因为它在扫描目录。之后 zsh 会在~/.zcompdump里缓存这个索引后续启动就快了。但这里有个坑如果你装了一堆插件、$fpath变了缓存就会失效重新扫描如果不处理你会觉得时快时慢。我用的方式是这样# ~/.zshrc autoload -Uz compinit # 每天最多重建一次补全缓存 if [[ -n ${ZDOTDIR:-$HOME}/.zcompdump(#qN.mh24) ]]; then compinit else compinit -C fi(#qN.mh24)是 zsh 的 glob 限定符语法大意是“匹配存在且修改时间在 24 小时内的文件”。存在就带-C跳过安全检查直接读缓存不存在就完整重建。这一招在机械硬盘或者网络文件系统上收益特别明显。注意-C会跳过补全函数的完整性检查。如果你在多用户机器上且$fpath里有别人可写的目录慎用-C。3.2 几个值得开的小开关compinit之后可以再加几行配置把补全的行为调得更贴合习惯。我常用的几条# 补全菜单第一次 Tab 列出第二次 Tab 进入选择 zstyle :completion:* menu select # 补全候选带颜色和分组描述 zstyle :completion:* list-colors ${(s.:.)LS_COLORS} zstyle :completion:* group-name zstyle :completion:*:descriptions format %F{yellow}-- %d --%f # 大小写不敏感 部分匹配 zstyle :completion:* matcher-list m:{a-z}{A-Za-z} r:|[._-]* r:|* # 近似纠错敲错一个字母也能给建议 zstyle :completion:* completer _complete _correct _approximatematcher-list那行是最值得抄的。改完之后你可以用小写补全大写的路径、用cd /u/lo/bi补到/usr/local/bin。completer里加上_approximate之后命令名敲错一个字母按 Tab它会给你“你是不是想输入 xxx”的候选这个在记不住长命令名的时候非常有用。3.3 给自己的内部脚本写补全这是 zsh 相对 bash 的一个明显优势自定义补全函数写起来结构清晰得多。假设你有一个内部工具叫deployctl支持deployctl [env] [service]两个参数环境只有 dev/staging/prod 三个值。补全函数大概这样写# 放到 $fpath 下任意目录文件名必须叫 _deployctl #compdef deployctl _deployctl() { local -a envs services envs(dev staging prod) services(${(f)$(deployctl list-services 2/dev/null)}) _arguments -C \ 1:environment:(${envs[]}) \ 2:service:(${services[]}) \ *::arg:-args } _deployctl $关键是文件命名必须是下划线加命令名然后用#compdef声明最后把文件所在目录加进fpath再跑一次compinit。相比 bash 的complete -Fzsh 的_arguments把位置参数、可选参数、互斥关系都描述得干干净净可读性高一个档次。我自己维护了一个~/.zsh/completions/目录专门放这些内部工具的补全在zshrc里加一行fpath(~/.zsh/completions $fpath)就够了注意这一行必须在compinit之前。4. 插件框架的取舍全量套用和按需组装差在哪4.1 一把梭的框架和十几个手动 source 文件刚上手的时候几乎所有人都会用现成的插件框架因为一行命令就能把补全、语法高亮、自动建议全部装好。这没什么问题问题出在后面你想要加一个自己写的小函数发现不知道该往哪放你想删一个用不上的插件发现它已经被框架接管了你打开新窗口发现要等半秒因为框架在加载二十多个插件。我用过好几种方案体感上的差异主要在三块启动耗时、配置可读性、出问题时排查难度。方案启动耗时典型上手成本排查难度适合谁现成框架一把梭200-500ms极低较难配置分散刚切换、想快速见效手动 source 各插件50-120ms中等容易一目了然熟悉之后长期维护延迟加载函数触发30-80ms偏高中等需理解触发机制追求极致启动速度我自己现在的做法是中间那条路不用框架zshrc里手动 source 五六个插件全部加起来不到三十行。这样做的最大好处是可读性——任何时候打开zshrc我都能一眼看出这台机器上到底加载了什么出问题直接二分注释就能定位。4.2 延迟加载把不常用的东西推迟到第一次调用有些东西确实不常用但偶尔又需要比如版本管理相关的补全、容器相关的补全。这类插件每次启动都加载一遍是浪费。延迟加载的思路是启动时只定义一层的桩函数真正的加载发生在第一次调用时。# 一个通用的延迟加载小工具 lazy_load() { local func_name$1 plugin_file$2 eval $func_name() { unfunction $func_name source $plugin_file $func_name \\$\ } }原理很简单把同名函数定义成一个“替身”第一次调用时删掉自己、加载真身、再把参数透传过去。这样第一次调用慢一点点但后续所有会话的启动都省下了这段时间。我个人只对少数几个重插件这么做比如一些体积较大的补全定义。对每次都会用到的比如语法高亮延迟加载反而让第一次体验变差不值得。注意延迟加载的插件不能提供“启动时就需要生效”的功能比如修改bindkey或者注册precmd钩子。这类必须启动时加载。4.3 我的最小组合和选择理由如果让我只留四个插件我会选历史搜索比如fzf的 history 集成、语法高亮、自动建议、补全增强。理由分别是历史搜索解决的是“我明明执行过这个长命令但忘了长什么样”按CtrlR模糊搜一把比用箭头翻半天效率高一个量级。语法高亮解决的是“这条命令我会不会在当前目录下执行出错”输入时就能看到红色提示。自动建议把历史里最匹配的一条以灰色显示在光标后按右键接受日常重复性操作能省下大量击键。补全增强就是前面说的那套zstyle加一些额外的_*补全文件。这四样加起来几乎覆盖了所有交互里的高频痛点。剩下的各种花哨功能我试过一轮之后基本都删了——看着好看用一周就无感。5. 提示符设计把哪些信息放进第一行值得算一笔账5.1 PROMPT 里的转义和条件展开zsh 的提示符用PROMPT或PS1定义里面支持一套百分号转义比如%n用户名、%m主机名、%~相对家目录的路径、%F{颜色}开始着色、%f结束着色。最有用的是条件展开%(1j.后台任务.)这种写法只有条件成立时才显示某段内容。# 一个信息密度适中、不花哨的两行提示符 setopt PROMPT_SUBST PROMPT%F{blue}%~%f %(?.%F{green}.%F{red}[%?]%f) RPROMPT%(1j.%F{yellow}[jobs]%f.)%(?.%F{cyan}%D{%H:%M}.%F{red}%D{%H:%M})第一行只放路径和上一条命令的退出码退出码为 0 时不显示非 0 时以红色方括号显示。第二行右提示符放后台任务数和当前时间。这里有个我自己坚持的原则第一行只放“必须马上知道”的信息。路径和退出码属于这一类。用户名和主机名我全部去掉了因为绝大多数时候是本地单机加了只是噪音。如果经常在多台机器之间跳那主机名就必须加不然容易敲错地方。5.2 右提示符的取舍和长命令折叠RPROMPT挺好用但有个很实际的坑当你的命令行特别长、超过了终端宽度右提示符会顶到左边把内容挤乱。解决办法是在RPROMPT里加判断或者在命令太长时自动隐藏# 命令长度超过一定值时隐藏右提示符 RPROMPT%{$(( COLUMNS - ${#${(%):-$PROMPT}} - 20 0 )) echo %F{cyan}%D{%H:%M}%f}这个写法略绕属于能用但不好维护的类型。更清爽的做法是用precmd钩子在每次画提示符前动态设置set_rprompt() { if (( ${#BUFFER} COLUMNS - 20 )); then RPROMPT else RPROMPT%F{cyan}%D{%H:%M}%f fi }配合zle-line-pre-redraw之类的事件可以做到输入过程中实时更新但这一步已经有点过度工程了。我的建议是先用简单的固定右提示符真被挤烦了再上动态方案。5.3 主题别成为启动时间的黑洞现在流行的提示符工具有几个配置现成、开箱好看但要清楚一件事它们会在每次画提示符时执行外部命令去收集信息分支名、版本、状态这些子进程开销会直接体现在每次回车之后的延迟上。判断方法很简单敲一个空回车感觉一下“到下一个提示符出现”之间有没有肉眼可辨的停顿。如果有打开它的配置把用不上的模块全关掉尤其是版本号检测、云环境检测这类每次都要读文件的模块。提示一个粗糙但有效的自测办法是在慢速机器上对比——把提示符主题临时改成PROMPT$ 如果回车响应立刻变快那问题就在主题上不用怀疑别处。6. 启动性能从三百毫秒压到八十毫秒的排查链路6.1 先量别猜打开新终端觉得慢第一反应通常是“肯定是我插件装多了”然后开始瞎删。这个顺序是错的得先量。最直接的方法是用 zsh 自带的zprof# 放在 .zshrc 最顶部 zmodload zsh/zprof # 放在 .zshrc 最底部 zprof下次启动时它会打印一张表按累计耗时排序前几名一目了然。实测下来耗时排名靠前的往往是这几类compinit重建缓存、版本管理工具的初始化脚本、nvm之类的环境加载、还有某些框架的全量插件扫描。第二种方法是给每个配置段打时间戳# .zshrc 顶部 zmodload zsh/datetime typeset -F SECONDS _ts_start$SECONDS # 每段之间插入 _log_ts() { print -rP %F{yellow}[$(( SECONDS - _ts_start ))]%f $1 2 } _log_ts after compinit这种方式适合定位“到底是我自己写的哪一段慢”比zprof更直观。6.2 我实际遇到过的三个元凶第一个是nvm之类的版本管理脚本。它们默认会在启动时做一堆路径拼装和版本检测动辄一百多毫秒。解决办法是延迟加载不加载环境只在真的调用node、npm时再初始化。社区有现成的延迟加载脚本核心思路就是把node定义成函数第一次调用时才 source 真实环境。第二个是compinit每次都完整重建。前面讲过加日期判断和-C就解决了。第三个出乎我意料某些主题脚本里做了git status调用而且是在precmd里每次画提示符都执行一次。在大型仓库里这个调用能到几十毫秒表现就是“在这个项目目录下敲回车特别卡换个目录就好了”。定位方法就是换个空目录试试如果立刻变快那八成是这个问题。6.3 优化前后的对照我把自己的zshrc优化过程记录下来大概是这么个轨迹阶段启动耗时做了什么初始框架全量约 380ms装了框架默认插件全开关掉不用的插件约 210ms只留四五个核心插件补全缓存优化约 140mscompinit -C加日缓存判断延迟加载重量级工具约 95ms版本管理、云工具延迟加载移除主题的外部调用约 80ms提示符改为纯内置转义测量方式统一用time zsh -i -c exit跑五次取中位数避免单次抖动。这个命令的前提是你得在zshrc里没有会阻塞的交互提示否则量出来全是等待时间。7. 那些让人抓头发的报错和排查路径7.1 “can only be called from completion function”这个报错我见过太多次典型场景是在zshrc里直接调用了_arguments或者在某些不该出现的地方用了补全函数。根本原因是补全函数只能在补全上下文里被调用你在普通脚本或者配置里直接调它它拿不到补全环境就报这个。排查思路是往上找调用栈看这个补全函数是被谁触发的。常见的几种误用包括把补全定义文件直接source到zshrc正确做法是放进fpath让compinit去扫描、在补全函数里调用了非补全上下文的外部命令。7.2 “no matches found” 和通配符展开zsh 默认会在通配符匹配不到任何文件时直接报错no matches found而不是像 bash 那样把字面量原样传给命令。这个差异把不少人坑过尤其是用find或者某些命令行工具时写了带方括号的参数。举个例子你想跑grep foo[0-9] file.txt不加引号的话 zsh 试图把它当 glob 展开匹配不到就报错。解决办法有两个给参数加引号推荐或者关掉这个行为# 不推荐全局关闭但可以在特定命令上放开 setopt no_nomatch我自己的做法是保留nomatch它其实能帮你早发现通配符写错只在个别确实需要字面量的场景用引号规避。保持这个严格性是有好处的比如rm *.tmp在当前目录没有 tmp 文件时bash 会把*.tmp原样传给rm然后报文件不存在而 zsh 直接拒绝执行某种意义上更安全。7.3 历史记录不共享、退出后丢失刚切换的时候很容易遇到一个窗口敲的命令另一个窗口按上箭头找不到或者关掉窗口之后历史就没了。原因有两个。一是 zsh 默认的历史文件写入时机和 bash 不同可能需要显式配置。二是多个窗口并发写同一个历史文件时需要加锁。我的配置是HISTFILE~/.zsh_history HISTSIZE50000 SAVEHIST50000 setopt INC_APPEND_HISTORY # 命令执行后立即追加不等退出 setopt SHARE_HISTORY # 多个会话共享同一份历史 setopt HIST_IGNORE_ALL_DUPS # 重复命令只保留一条 setopt HIST_IGNORE_SPACE # 以空格开头的命令不记录 setopt HIST_VERIFY # 从历史调出时不立即执行先给我编辑HIST_IGNORE_SPACE这条特别实用处理敏感参数的命令前面加个空格就不会被写进历史文件。INC_APPEND_HISTORY加上SHARE_HISTORY之后多窗口之间基本不会丢记录了。7.4 别名和函数打架zsh 里函数和别名的优先级、生效时机有些微妙。常见的困惑是“我明明定义了别名为什么脚本里没生效”。原因是别名在非交互 shell 里默认不展开这是有意为之避免脚本被用户环境干扰。另一个常见现象是alias lsls --colorauto之后某些依赖ls原始行为的脚本出问题。绕过办法是在命令前加反斜杠或者command\ls或者command ls会跳过别名。这个方法值得记住排查“是不是别名搞的鬼”时第一件事就是加个反斜杠试试。8. 把 zsh 当脚本解释器用之前先搞清楚这些差异8.1 数组下标从 1 开始这是最容易翻车的一条。bash 的数组第一个元素是${arr[0]}zsh 里是${arr[1]}而${arr[0]}在 zsh 里指向的是整个数组效果类似$。一个从 bash 抄过来的循环在 zsh 里跑出来的结果会整体偏移一位而且不会报错属于最难发现的那类问题。# zsh 里的正确写法 arr(a b c) echo ${arr[1]} # a echo ${arr[0]} # a b c整个数组 echo ${(k)arr} # 1 2 3所有下标8.2 词分割的默认行为不同bash 在展开未加引号的变量时会做词分割vara b; for x in $var会循环两次。zsh 默认不做词分割这个循环只跑一次$var整体作为一个元素。这个差异导致大量 bash 脚本在 zsh 下行为完全变了。反过来zsh 提供了更明确的分割语法${var}显式要求按空白分割或者${(s:,:)var}按逗号分割。用显式语法替代隐式规则脚本意图会更清楚。8.3 需要兼容时用 emulate如果确实有脚本必须同时兼容两种 shell可以在 zsh 脚本开头加一句emulate -L shemulate -L sh会把当前函数的选项和行为切到 sh 兼容模式-L表示只在当前函数作用域内生效不影响调用者。这是比手动逐个setopt更省事的做法也是我推荐写 zsh 脚本时的标准开头。不过说到底我的态度还是需要严格保证可移植性的脚本老老实实写 bash 或 sh只有在确定目标环境就是 zsh 的情况下才用 zsh 的特性去换开发效率。两者别混着来混着来迟早出问题。最后分享一个我自己的小习惯zshrc里所有自定义函数和别名我都用注释分成“每天都用”“偶尔用”“备用别删”三块放在文件最上面。这样每次想清理的时候从最下面那块的末尾往上删就行不用通读全文。这个习惯给我省过好几次误删——有一次差点把一个用了三年的部署函数删掉因为它当时被我归在“偶尔用”那块的最后一个。