分号、&& 与 ||：每天敲一万次、却极少人真正理解的命令链 Cut

每天早上我都会收到"我的 shell 脚本写崩了"的求助，八成问题不在逻辑，而在这一行：

git pull && deploy.sh || echo "部署失败"

看起来天经地义：拉代码成功就部署，失败就喊一声。但如果你实际测试过，会发现它有两个坑——"部署成功"时那条"部署失败"可能会喊出来，而"部署脚本自身崩溃"时也不一定会走那个分支。这是 CLI 里最常用、也最容易被误解的机制，值得用五分钟讲清楚。

核心规则：先看前一条命令的退出码

三个连接符的差别只用一句话就能说完：

;（分号）：上一条跑完就跑下一条，不管成功失败，都执行。它是"无条件接力"。
&&（与）：上一条成功（退出码 0）才执行下一条，失败就整段停下来。
||（或）：上一条失败才执行下一条，成功就跳过。

退出码（exit code）是一切的基础：0 代表成功，非 0 代表失败。你可以随时用 echo $? 查看上一条命令的退出码，也可以用 # 在注释里记下"为什么要非 0"。

git pull
echo "git 退出码：$?"   # 0 = 成功，128 开头通常是致命错误

场景：三个操作串起来

假设你要完成"备份数据库 → 跑迁移 → 发通知"，并且迁移失败必须终止，否则会把坏代码发出去：

pg_dump mydb > backup.sql && migrate-v2.0 && notify.sh "迁移完成"

&& 的好处：pg_dump 失败（磁盘满、权限错），后面的就不会跑，你把故障圈在最小半径。set -e 可以让整个脚本在任何失败时中止，但它是全局的、容易误伤（比如 grep 搜不到东西也是非 0），精细控制还是靠显式 && 舒服。

什么时候该用什么

需要"成功才继续"：用 &&。构建、迁移、部署，每一步的失败都会污染下一步。

需要"失败也别停下来，先记录"：用 ;。

npm run build; echo "构建结束（成功与否都会打印）"

或者更优雅地用 || 接失败分支：

npm run build || { echo "构建失败" >&2; exit 1; }

需要"二选一"：用 || 接兜底。
- command1 || command2：command1 成功就跳过，失败才跑 command2。
- 但上面开头那个 A && B || C 的写法要慎用。直觉上"成功走 B，失败走 C"是对的，但有第三个情况：A 成功、B 失败时，C 也会跑。如果你的 B 是 deploy，你想用 C 做"部署失败告警"，这倒是对的；但如果 C 是别的副作用，就很容易出现"部署成功还在执行 C"的诡异 bug。安全写法：
```
if git pull; then
  deploy.sh
else
  echo "拉代码失败，中止" >&2
  exit 1
fi
```
语义一目了然，没有歧义。

一个真实的坑：`echo` 掩盖了失败

很多人写：

$TOOL_MIGRATE || echo "二级数据迁移出错"

看起来 || 只会在 $TOOL_MIGRATE 失败时输出告警。但如果你加过 set -x 或 debug 日志，会发现 $TOOL_MIGRATE 真的失败了，而且告警打印了——没错，那是对的；问题是很多团队的告警通道在这台机器上根本不通（网络隔离、log 服务重启），echo 只是"看起来兜住了"，实际上是静默失败。|| 不保证你的 fallback 也成功，它只保证"成功时不跑、失败时跑"。所以告警要双通道，且用 echo ... >&2，再配合 cron/atop/logwatch 做最终兜底。

管道与 `;` 的结合

管道 | 传递的是 stdout，退出码默认取最后一个命令的退出码：

cat data.json | jq '.items' > out.json && echo "OK"

如果 jq 出错了（字段不存在），echo "OK" 还是会打印，哪怕 out.json 是空的或者报错。要"任何一段失败都整段失败"，需要 pipefail：

set -o pipefail
cat data.json | jq '.items' > out.json && echo "OK"

现在 jq 失败，管道整体非 0，&& 后面的就停了。这是处理数据链（日志采集 → 转换 → 入库）最常被忽略的一行。

何时不该用命令链

超过 3~5 步的流程不要写成一行链。一行代码越长，可读性越差，且退出码一多你就追不清了。超过 3 步，写个 .sh 文件，每步一个函数，函数开头 set -euo pipefail，每步结束打一条 [step] 日志。
链在前台跑的状态、错误处理、重试：链式命令没有重试、没有超时、没有分段状态。如果这是生产脚本，至少加 timeout 和手动 for i in 1 2 3; do ... && break; done 结构。
在交互式 shell 里调试链式命令：Ctrl-Z 会挂起整段链，恢复时容易乱序。调试时拆成单步执行。

常见误判

"失败跳过"是 ||，不是 ;。 ; 永远执行下一条，它没有"跳过"的概念。
set -e 不是万能的。 它在全局层面对 &&、||、if 的条件语句有豁免（这些是正常控制流，不算错误），这在 make 的 recipe、Ansible 的 inline task 里经常踩坑。显式 &&/|| 永远优先。
管道退出码默认只看最后一个命令。 上面的 && jq ... && echo OK 不会在 jq 失败时停，除非加 pipefail。
$? / $status 取上一次命令的退出码。 注意是"上一条"，写了 echo 之后 $? 就变成 echo 的（echo 基本恒为 0）。取退出码要立刻取，别中间插任何命令。

清单：写链前过一遍

这一步失败，下一步有没有必要继续？是 → ;；否 → &&
|| 的兜底分支本身会不会出错？会 → 用函数封装，函数内再设兜底
有管道，是否加了 pipefail？
关键错误码是不是要单独判断（别只靠非 0/0 二分）？
超过 3 步？考虑写脚本，别继续加 &&
在带 set -e / set -x 的环境里跑吗？是否会被静默忽略（条件语句豁免）？

小结

命令链本身很轻，但它的静默路径也多。把 && 当"守护门"、; 当"无脑接力"、|| 当"兜底通道"，再用 explicit if/else 处理"二选一边"、pipefail 处理管道，你可以把脚本从"能跑"推到"跑崩时一眼看出崩在哪一步"。

最后一句反直觉但很重要的话：能写成 if/else 的分支，就不要用 || 的隐式语义。 下一位接手你脚本的人，包括六个月后的你，会感谢你的。