🔑 Shell 里的 pipefail：为什么前面的命令明明失败了，脚本还显示成功？
很多人第一次写 Shell 管道时都会踩这个坑：
但这里还有个常见误会：
🧪 课后一题：执行
💡 易混淆点：
很多人第一次写 Shell 管道时都会踩这个坑：
cat missing.txt | grep hello | wc -l，明明最前面的 cat 已经报错了，整条命令最后却可能返回成功。原因不神秘，Shell 对管道的默认设计就是“看最后一个命令的退出状态”。这在交互式命令行里很实用，因为你常常真正关心的是最后产出的结果，比如 grep 有没有匹配到、wc 有没有算完；但一进脚本，这个设计就容易把错误吞掉，让 CI 绿灯、日志好看、结果却是错的。pipefail 就是拿来修这个默认行为的。打开 set -o pipefail 之后，只要管道中有一个命令失败，整条管道就会被判定为失败。这样一来，上游读文件失败、网络请求失败、解压失败，不会再被下游命令“洗白”。很多自动化脚本都会把 set -euo pipefail 放在开头，核心不是仪式感，而是尽早把坏数据拦住，别让后面的命令在垃圾输入上继续跑。但这里还有个常见误会：
pipefail 不是“返回第一个失败”，而是“返回最后一个失败的非零状态”。这意味着它能告诉你这条管道出问题了，却不负责替你定位是哪一段坏了。真要查，就得看 PIPESTATUS，或者把长管道拆开。好代码不是往一条命令里塞五六段玄学管道，而是让每一步都能单独验证。否则你得到的不是简洁，是一条难以调试的黑盒。🧪 课后一题：执行
false | true 时，默认情况下退出状态是多少？开启 set -o pipefail 之后又是多少？答案：truefalse💡 易混淆点：
pipefail 只影响“管道”里的退出状态，不会自动让所有脚本更安全；像变量未定义、普通命令失败、子命令逻辑错误，还要分别靠 set -u、set -e 和清晰拆分步骤来处理。
