head 正常结束，脚本却拿到 141
yes | head -n 1 看起来是个正常管道：head 打印一行就退出，任务已经完成。可在 Bash 里加上 set -o pipefail 后，整条管道返回 141。下游的工作结束了，上游却被记成失败。
这不是 head 没拿到数据。它读到一行后主动关闭管道，yes 继续写入时发现读端已经消失，内核给它发了 SIGPIPE。Bash 3.2.57 在这次本机运行里把这个信号结果表现为 141。
看到管道非零时，常会先怀疑上游命令出错。这个例子里恰好相反，上游只是来不及把无限输出写完。若脚本开了 set -euo pipefail，非零状态还可能让后面的清理或汇总逻辑根本没有机会运行。
两种管道设置的返回值
在 macOS 自带的 Bash 3.2.57 上分别运行同一条管道，结果如下。这里把 head 的输出丢弃，只观察状态：
| shell 设置 | 结果 | 含义 |
|---|---|---|
| 默认设置 | 0 | 管道状态取最后一个命令 head 的状态 |
set -o pipefail |
141 | 任一命令非零，管道也非零 |
实测命令和输出：
[without_pipefail] shell_exit=0
pipeline_status=0
[with_pipefail] shell_exit=0
pipeline_status=141
[bash_version] shell_exit=0
GNU bash, version 3.2.57(1)-release (arm64-apple-darwin25)
单独检查 set -euo pipefail; yes | head -n 1 时，shell 退出状态也是 141，后续命令没有运行。证据脚本只在本机调用 Bash，没有依赖外部服务。
默认管道状态只看最后一个命令，所以 head 成功时整条管道就是 0，即使上游已经被信号打断。pipefail 改了这个汇总规则。它返回最右侧那个非零命令的状态；上游的 SIGPIPE 因而不再被 head 的成功覆盖。
提前停止的消费者会改变上游结局
这个现象并不限于 yes。只要消费者读够内容便退出，上游就可能继续写入一个已经关闭的管道。生成量大的搜索结果接 head，或日志生产命令接只取开头几行的工具，都值得检查是否出现这种情形。输出少时，上游可能已经写完，管道仍返回 0；输出多时，是否触发 SIGPIPE 还受缓冲和调度影响。因此不能把某次返回 0 当成管道永远安全的证明。
141 是这次 Bash 对 SIGPIPE 的状态表示，不应当作所有程序、所有 shell 都必须给出的固定文本。判断时要看具体命令的退出状态和 shell 的管道规则。也不要仅凭「head 已经输出了」就认定上游完整完成，输出内容正确与生产命令成功是两件事。
让脚本知道这是预期停止
pipefail 能暴露上游失败，也会把「消费者主动结束」算进失败。它的价值在于少吞掉真实错误，不是让每条管道都自动正确。对需要完整输出的命令，保留 pipefail 更稳；如果下游本来只取一小段，就要明确处理上游可能收到 SIGPIPE 的情况。
一种简单做法是先把完整结果写到文件，再从文件中截取。这样生产命令和展示命令分开，生产状态不会被读端提前关闭干扰，代价是多一次磁盘读写。若不想落盘，也可以单独检查各段命令状态，但必须区分「预期的 SIGPIPE」和真正的失败，不能把所有非零状态一概吞掉。
我会保留 pipefail，但不会把每条 producer | head 都当成无害的展示管道。需要上游完整执行时，让它写完再检查；只想提前停止时，把这种停止当成控制流明确处理。
