Fish: 一条鱼

终端的光标在闪。屏幕上是一行还没敲完的命令，git push origin 后面跟了一个忘了名字的分支。手指悬在 Tab 键上方，按下去，什么也没发生。又按了一次，还是什么也没有。

在这个由字符构筑的黑色深海里，无数的终端行者都在寻找一艘称手的潜艇。Bash 像是一艘古老而沉重的破冰船，坚毅却晦涩，它的航线图（脚本）充满了历史遗留的暗礁——它从 1989 年游到现在，三十六岁了，依然不会告诉用户分支叫什么。Zsh 则像是一艘需要精密改装的核潜艇，虽然功能强大，但若不花上数个夜晚配置那些复杂的 .zshrc 配置文件，它甚至无法启动引擎。

旁边工位的同事敲了一行 docker run，按下 Tab，屏幕上弹出了一列参数，每个参数后面跟着一行说明文字——这个容器要分配多少内存，那个卷要挂载到哪里。他甚至没有装过任何补全插件。

问他用的什么 Shell，他回了四个字母:fish

fish，即Friendly Interactive Shell。就在这片充满神秘代码符号的海洋中，它没有背负沉重的历史包袱，也没有让人望而却步的配置门槛。fish就是一条鱼，生来就是为了游出最强的易用性。2005 年 2 月 13 日，一个叫 Axel Liljencrantz 的瑞典人把它放进了水里。二十年后，这条鱼从 C++ 游到了 Rust，GitHub 上攒了三万颗星，却始终只做一件事——让命令行不再需要配置就能用。

水里的色彩

Fish 有一双能看见颜色的眼睛。

在 Bash 里敲命令，所有字都是同一个颜色。敲对了是白色，敲错了也是白色，直到按下回车，系统报一段错，才知道刚才把 git 打成了 gir。

Fish 不等回车。每敲一个字母，它都在实时检查——这个命令存在吗？参数合法吗？路径指向的文件真的在那儿吗？存在就标绿，不存在就标红，有效路径加下划线，无效路径什么也不加。还没按回车，屏幕已经把答案写在了脸上。

# 在 fish 中输入时：
git comm<光标>
# "git" 显示为绿色（命令存在）
# "comm" 显示为灰色（未完成的输入）
# 按 Tab 后自动补全为 "commit"，并显示参数提示

这不是插件，不是配置项，不是某个发行版的特殊补丁。Fish 从源码层面把语法高亮焊进了交互引擎。2005 年的第一个版本就有这个功能，那时候 Bash 已经十六岁了，还是没有。

Zsh 能做到吗？能。需要装 zsh-syntax-highlighting 插件，在 .zshrc 里 source 一下，再重启终端。一共大约三步。Fish 是零步。

记忆的洋流

Fish 不会遗忘。

在终端里反复输入同一条命令是日常——每天 git status 几十次，docker compose up 几次，ssh 到同一台机器几次。Bash 的做法是按上箭头，一条一条往前翻历史，或者按 Ctrl+R 搜索，搜到了再搜一次，搜过头了再往回搜。

Fish 的做法是：什么都不做。

输入 gi 的时候，屏幕右侧浮现一行浅灰色的字——git status，这是上一次输入过的命令。按右箭头，整行接受。输入 doc 的时候，浮现 docker compose up -d。按右箭头。结束。

这不是补全，这是 autosuggestion。Fish 在背后维护一份完整的历史记录，每当输入框发生变化，它就在历史里找最近一次以当前输入为前缀的命令，用浅灰色显示在后面。灰色意味着"这不是当前正在输入的内容，只是建议"，右箭头意味着"接受这个建议"。

Julia Evans 是加拿大一位知名的技术博主，用 Fish 超过十年。她在 2024 年 9 月的博客里写了一段话，大意是：Fish 最让她着迷的细节之一，是它能自动补全包含路径的命令。输入 cd 然后按 Tab，它不仅补全目录名，还会根据上下文把最可能的目标排在最前面。

Bash 和 Zsh 也能做到类似效果，但需要安装 fzf 之类的工具，配合 bash-preexec 或 Zsh 的钩子机制，再写几行配置脚本。Fish 把这件事做成了默认行为。

读懂手册的鱼

大多数 Shell 的 Tab 补全是这样的：装了一个工具，补全就有了；没装，就没有。补全规则是手写的，散落在各处，有的工具提供，有的不提供。

Fish 读书。

确切地说，Fish 会读系统里安装的所有 man page——手册页。它有一个叫 fish_update_completions 的内置命令，运行时扫描系统上所有的手册页，解析其中关于命令行参数的描述，自动生成对应的补全规则。每条补全还附带从手册里提取的说明文字。

输入 tar 按 Tab，屏幕上不只列出参数，还告诉每个参数是干什么的。输入 grep 按 Tab，-i 旁边写着 "ignore case"，-r 旁边写着 "recursive"。这些信息不是 Fish 团队手写的，是从系统已有的手册里自动提取的。

这意味着一个奇妙的连锁反应：在系统上装一个新工具，只要它带了手册页，Fish 就能自动学会它的参数补全。不需要装补全插件，不需要改配置文件，不需要重启 Shell。下次打开终端，它已经会了。

Bash 需要靠 bash-completion 项目，Zsh 需要靠 _comps 体系和各种插件。它们都在追赶一个 Fish 从第一天就内建的能力。

缩写而非别名

Bash 用户习惯在 .bashrc 里写别名：

alias gs='git status'
alias gp='git push'
alias dc='docker compose'

别名的问题是：它是一个黑盒。输入 gs 回车，Bash 执行 git status，但屏幕上显示的还是 gs。如果 gs 碰巧和某个系统命令重名，排查起来就很麻烦。别名也不会被传递给子进程，在脚本里不生效。

Fish 提供了一个不同的东西，叫 abbreviation——缩写。它在输入时展开：

# 在 fish 配置中定义：
abbr -a gs git status

# 输入 gs 后按空格：
# 屏幕上自动变成 "git status"
# 然后继续输入参数

输入 gs，按下空格，gs 在眼前展开成 git status。回车之前，能清楚地看到将要执行的真实命令。展开发生在输入层面，不是执行层面，所以在脚本里 gs 不会生效——脚本里只认完整命令，没有歧义。

这个设计折射出 Fish 的一个核心理念：交互层和脚本层应该用不同的规则。交互层追求效率和便捷，脚本层追求确定性和可移植性。Bash 把两层混在一起，用同一套语法服务两个完全不同的场景，结果两头都不讨好。

多行粘贴的安全感

终端用户都有过这种经历：从网页上复制一段 Shell 脚本，粘贴到终端，其中包含多行命令。在 Bash 里，粘贴的每一行都会被立即执行，第一行还没看清，第三行已经跑完了。如果中间有 rm -rf 之类的危险命令，后悔都来不及。

Fish 的做法不同：多行粘贴时，它把所有行放在同一个输入缓冲区里，以一个完整的多行命令形式呈现。用户可以看到所有将要执行的内容，检查无误后再按回车。

这听起来是一个小功能，但它改变了一种根本性的心理状态——从"粘贴即执行"到"粘贴即审阅"。Julia Evans 在博客里专门提到了这一点，说这让她粘贴多行命令时安心得多。

一张对照表

三条 Shell 走了三条路。Bash 是守旧派，Zsh 是改造派，Fish 是另起炉灶派。

维度	Bash	Zsh	Fish
诞生年份	1989	1990	2005
语法高亮	无（需插件）	需插件	内建
自动建议	无（需插件）	需插件	内建
Tab 补全	手动配置	手动配置	自动解析 man page
开箱即用程度	低	中（依赖框架）	高
POSIX 兼容	是	大部分	否
脚本可移植性	高	中	低（需 fish 安装）
配置方式	编辑 .bashrc	编辑 .zshrc + 框架	fish_config 网页界面
4.0 版语言	C	C	Rust

Bash 像一辆手动挡卡车——哪里都能开，零件哪里都有，但离合器要自己踩。Zsh 像一辆改装车——动力强劲，但得花一个下午装大包围、换避震、刷 ECU。Fish 像一辆电动车——坐进去就能开，不需要热车，不需要换挡，不需要去加油站。

不守规矩的鱼

Fish 有一个"原罪"：它不兼容 POSIX。

POSIX 是 Unix 世界的一套标准，定义了 Shell 脚本应该怎么写。Bash 基本遵循 POSIX，Zsh 也大部分兼容。Fish 从一开始就拒绝遵守。

在 Fish 里定义变量不是 VAR=value，而是 set VAR value。命令替换不是 $(cmd)，而是 (cmd)。条件判断不是 if [ ... ]; then ... fi，而是 if ... ... end。函数定义不是 function f() { ... }，而是 function f ... end。

这意味着所有为 Bash 写的脚本——系统启动脚本、软件安装脚本、CI/CD 流水线——都不能直接用 Fish 跑。把 Fish 设为默认 Shell，某些系统脚本可能会出问题。

这是 Fish 被批评最多的地方。但 Fish 的设计文档里有一句话，可以看作对这种批评的回应。原话是：Fish should be user-friendly, but not at the expense of expressiveness. Most tradeoffs between power and ease of use can be avoided with careful design.

翻译过来：Fish 应该对用户友好，但不以牺牲表达力为代价。易用性和功能之间的大多数权衡，都可以通过仔细的设计来规避。

Fish 团队的立场很明确：POSIX 是 1988 年制定的标准，它的语法设计承载了几十年的历史包袱。如果目标是写脚本，用 Bash。如果目标是交互使用，为什么非要背着三十多年前的包袱？

事实证明，这个判断是正确的。大多数开发者同时使用两种 Shell——用 Fish 做日常交互终端，用 Bash 跑脚本和自动化任务。两者各司其职，互不干扰。POSIX 不兼容在实践中几乎不是一个问题，因为没有人用 Fish 去跑 #!/bin/sh 的脚本。

网页里的控制台

Fish 有一个独一无二的功能：fish_config。

在终端里输入这个命令，Fish 会启动一个本地 Web 服务器，自动打开浏览器。在浏览器里，可以通过图形界面选择提示符样式、配色方案、查看已定义的函数和变量、浏览历史命令记录。

这听起来"不 Unix"——Unix 用户习惯用文本文件配置一切，用命令行操作一切。但 Fish 的判断是：配置 Shell 的体验本身就应该友好。一个新手第一次打开 Shell，不应该面对一个空的 .bashrc 文件和一堆不知道语法的配置选项。他应该看到几个预设的提示符样式，点一下就能用，觉得不够再去看文本配置。

这又是那个设计哲学：零配置为起点，有配置为进阶。先让工具能用，再让工具可调。Bash 和 Zsh 的路径是"先配置才能用"，Fish 的路径是"先能用，想配置再说"。

忒修斯之鱼

2024 年 12 月 28 日，Fish 团队发布了一篇博客，标题叫"The Fish of Theseus"——忒修斯之鱼。

忒修斯之船是一个古老的哲学问题：如果一艘船的木板被一块一块替换，直到所有木板都是新的，它还是原来那艘船吗？

Fish 团队用这个名字，是因为他们做了一件疯狂的事：把 Fish 的全部代码从 C++ 重写成了 Rust。不是一部分，是全部。0% C++，100% Rust。2025 年 2 月 27 日，Fish 4.0 正式发布。

重写的原因不复杂。C++ 是一门强大但复杂的语言，内存安全要靠开发者自己保证，构建系统（CMake）的配置文件越来越难以维护，新贡献者面对 C++ 代码库的门槛很高。Rust 提供了内存安全保证，构建工具（Cargo）开箱即用，类型系统更现代，社区也更活跃。

整个重写过程持续了大约一年。团队的策略是"全部重写完再发布"，不做渐进式迁移——不会有半个 C++ 半个 Rust 的中间状态。这需要耐心，但也保证了最终产出的干净。

Fish 4.0 发布后，社区反应普遍正面。Lobste.rs 上一位用了 Fish 十三年的用户说："对 Rust 重写没什么特别的感觉，但一切都很顺畅。"这正是重写的目标——用户不应该感受到任何变化，除非他们去看源码。

鱼为什么游得最快

回到最初的问题：为什么推荐 Fish？

不是因为它的语法高亮比 Zsh 的插件好看多少个色号，不是因为它的自动建议比 fzf 快多少毫秒，不是因为它的补全覆盖了多少个命令。这些具体优势都存在，但它们不是核心。

核心是 Fish 对"易用性"的理解和所有其他 Shell 不同。

Bash 认为：易用性是兼容性，是到处都能跑。Zsh 认为：易用性是可配置性，是给用户最大的自由。Fish 认为：易用性是开箱即用，是零配置就有全部功能，是把开发者从"配置工具"这件事里解放出来。

这三种理解都没有错，但它们面向的是不同的人。Bash 面向系统管理员和脚本作者，Zsh 面向喜欢折腾的极客，Fish 面向只想把命令跑起来的人。

而"只想把命令跑起来"这件事，恰恰是绝大多数开发者的日常。不是每个人都享受写 .zshrc，不是每个人都记得 bindkey '^R' history-incremental-search-backward 的语法。大多数人打开终端，只是想 cd 到项目目录、git 一下状态、docker 起一个容器、ssh 到服务器。

Fish 把这些日常操作的摩擦力降到了最低。不需要配置，不需要记忆快捷键，不需要安装插件框架。装上 Fish，打开终端，开始用。语法高亮在，自动建议在，Tab 补全在，缩写在，多行粘贴保护在，网页配置界面在。

一条鱼不需要学游泳。它生来就在水里。

这正是 Axel Liljencrantz 在 2005 年想要的东西。二十一年后，这个想法依然有效。