他写了个日志转发脚本,本地跑得好好的，一到线上就偶尔“莫名其妙”退出，退出码还是 141，没有明显报错，没有 OOM，也没有权限问题，查了半天，最后发现不是代码里哪一行写错了，而是碰上了 SIGPIPE，这个名字听起来很底层，离日常很远，但只要你写过命令行管道、做过网络服务、处理过日志转发，大概率已经和它擦肩而过很多次了。
先说人话版：SIGPIPE 是 Unix/Linux 里的一个信号，编号通常是 13，它出现的一个典型场景是：一个进程往管道或者 socket 里写数据，但另一头已经没有读者了，系统就会给写端发 SIGPIPE，默认情况下，这个信号会把进程直接终止，所以很多程序不是“逻辑崩了”，而是被系统一句“对面没人接了，你还写什么”给带走了，退出码 141 128 加 13，看到它，基本可以往 SIGPIPE 方向想一想。
举个特别生活化的例子,你拿水管给花浇水，这头水龙头开着，那头接水的人已经把喷头拔了，水还在往外冲，管子会憋一下，甚至甩你一身，SIGPIPE 很像系统在提醒你：下游已经断开，别再傻乎乎地灌了，但问题在于，有的程序会认真处理这个提醒，有的程序直接“倒地不起”，命令行里常见的 python big_log.py | head -n 20 就是典型：head 读够 20 行就退出了，前面的 Python 还在 print，管道读端没了，写端就可能收到 SIGPIPE，人看到的是 Python 脚本突然退出，实际上它是在往一个没人接收的管道里继续写。
我自己也踩过一个很具体的坑,之前写过一个日志采集小工具：一边 tail -f 业务日志，一边把数据通过管道交给压缩程序，压缩完再上传，某次磁盘满了，压缩程序提前退出，上游还在拼命写，结果采集进程直接消失，监控里只留下一个 141，我一开始怀疑内存泄漏，后来又怀疑权限，查了半天才意识到：下游断了，我还在往管道里塞数据，后来改成把写失败当成正常断链处理：捕获 EPIPE，关闭文件描述符，记录一条 warning，再按策略重启下游，问题才真正稳定下来，这个经历让我对 SIGPIPE 的印象特别深：它不是玄学，它是系统在告诉你“通信关系已经变了”。
另一个常见的实例在 Web 服务里，比如你做了一个消息推送接口，客户端连着，你不断往 socket 写数据，用户突然关掉页面、手机断网，或者中间代理把连接掐了，服务端如果还在往这个连接写，就可能遇到 EPIPE 或 SIGPIPE，很多新手会直接抄一句“忽略 SIGPIPE”，也就是把信号处理成 SIG_IGN，然后觉得万事大吉，可我的个人观点是：忽略 SIGPIPE 只是第一步，不是终点，你可以不让默认动作杀死进程，但必须检查 write 的返回值，看到 -1 和 EPIPE 后关闭连接、清理资源、停止重试，否则你只是把“进程突然死掉”换成了“进程活着但一直往死连接里写”，问题从明面转到暗面，更难查。
还有一点,不同语言和运行时的处理方式并不完全一样，C/C++ 里你可能需要显式处理信号；Python 里可能表现为 BrokenPipeError；Go、Node.js 这类运行时又会做一层封装，网上搜到一句 signal(SIGPIPE, SIG_IGN) 就复制粘贴，不一定适合你的场景，命令行工具有时默认被 SIGPIPE 终止反而是合理的，因为下游不要数据了，上游没必要继续跑；但长期运行的服务端程序，通常更适合把断链当成一种可处理的错误，而不是让整个进程退出，关键不是“记住某个万能写法”，而是搞懂数据流向：谁在写，谁在读，读端什么时候可能消失，写失败之后你的程序应该怎么收场。
所以我现在看 SIGPIPE，会把它当成一个很诚实的信号：它不负责替你修 bug，只负责告诉你管道断了，真正成熟的写法，是接受“下游可能先走一步”这个事实，把异常路径设计好，别怕看到 141，也别一看到就只会加一行忽略，先问自己：这个写操作失败后，我该关掉什么、记录什么、重试什么、放弃什么？想清楚这几个问题，SIGPIPE 就从“让程序悄悄退出的神秘信号”，变成了一个能帮你发现连接生命周期问题的老朋友。