🔑 为什么 Shell 管道默认会“吞掉”前面的错误？

在 Shell 里，很多人第一次写管道都会以为只要前面某一步失败，整条命令就算失败。实际不是这样。像 cat missing.txt | grep foo | wc -l 这种命令，Shell 默认只看最后一个命令的退出状态，也就是 wc -l。这意味着前面的 cat 就算已经报错，只要最后的 wc 正常结束，整条管道在很多脚本里仍然会被当成“成功”。

这个设计不是疏忽，而是早期 Unix 的取舍。管道的核心目标是把“数据流”接起来，让小程序像积木一样组合。Shell 把每个程序都当成独立过滤器，默认只关心最末端是否得到了可继续处理的结果，因为用户最常消费的就是最后一步的输出。这样做很简单，也兼容了大量老脚本，但代价是：如果你把它直接用于自动化，错误可能会悄悄溜过去。

真正踩坑通常发生在 CI、部署脚本和日志处理里。比如你写了 build_cmd | tee build.log，tee 几乎总能成功，于是即使 build_cmd 已经失败，脚本还是继续往下跑。表面看日志也有输出，实际上流程已经坏了。这种 bug 最烦人的地方就在于它不炸，它只是悄悄给你一个假成功。

所以后来大家常写 set -o pipefail。它的意思是：只要管道里任意一个命令失败，整条管道就失败。这样脚本才更像你脑子里想的那样工作。再配合 set -euo pipefail，Shell 会更早暴露问题，而不是帮你偷偷兜底。这里的重点不是“语法技巧”，而是态度：不要让脚本假装没事，错了就该尽快暴露。

不过 pipefail 也不是无脑全开就完事。有些命令失败是正常控制流的一部分。最常见的是 grep 没找到内容时会返回 1，这不一定表示异常。如果你开了 pipefail，又把这种返回值当成真正错误，脚本就会过度敏感。所以关键不是迷信某个选项，而是明确区分“业务上允许的未命中”和“真正的执行失败”。

🧪 如果执行 false | true，在 Bash 默认设置下整条管道的退出状态是多少？打开 set -o pipefail 后又是多少？答案：truepipefailfalse

💡 易混淆点：grep 返回 1 往往表示“没找到”，不等于程序出错；而 pipefail 关心的是退出码，不会替你判断这个 1 在业务上是不是合理。

#CS