默认情况下sigpipe会直接终止进程，因其默认行为是终止并生成core dump，且不可被忽略或自定义处理，仅当向无读者的socket或pipe写入时触发，需显式忽略（如signal(sigpipe, sig_ign)）并检查write()返回epipe错误。
为什么 SIGPIPE 会直接杀死进程
默认情况下，SIGPIPE 的行为是终止进程并生成 core dump。它不像 SIGTERM 那样可被忽略或自定义处理——只要你的程序向已关闭的 socket 或 pipe 写入数据，内核就立刻发送 SIGPIPE，且一旦未显式处理，进程当场退出。
常见触发场景包括：客户端断连后服务端仍调用 write()、子进程关闭了管道读端而父进程继续写、curl | grep 类管道中前一个命令提前退出。
- 不是所有 write 都会触发：仅当写入对象（如 socket、pipe）处于“无读者”状态时才发生
-
send()和write()行为一致；printf()等 stdio 函数底层仍调用 write，同样危险 - 即使你没注册
SIGPIPE处理器，它仍按默认行为终止进程——这是隐式风险
必须设置 SA_RESTART 吗？不，但 SA_RESTART 解决不了 SIGPIPE
SA_RESTART 只影响被信号中断后可自动重试的系统调用（如 read()、accept()），而 SIGPIPE 不会中断系统调用——它在 write() 返回前就已触发并终止进程。所以加 SA_RESTART 对 SIGPIPE 完全无效。
真正起作用的是显式忽略或捕获该信号：
- 最简方案：
signal(SIGPIPE, SIG_IGN)—— 全局忽略，后续write()失败返回 -1 并设errno = EPIPE - 若需日志或诊断，可用
sigaction()注册空处理器，但务必设sa_handler = SIG_IGN或明确 return，避免意外行为 - 不要在 handler 中调用
printf()、malloc()等非异步信号安全函数——哪怕只是记录一句“got SIGPIPE”也危险
PHP / Python 等高级语言也要手动处理 SIGPIPE 吗
是的，而且更隐蔽。这些语言运行时通常不屏蔽 SIGPIPE，其内置 I/O 函数（如 PHP 的 fwrite()、Python 的 sys.stdout.write()）底层仍是系统 write()。一旦管道断裂，进程照样被杀。
实操建议：
- PHP：启动时加
pcntl_signal(SIGPIPE, SIG_IGN)，并在事件循环中定期调用pcntl_signal_dispatch() - Python：执行
signal.signal(signal.SIGPIPE, signal.SIG_IGN)，注意需在主线程中设置，子线程不继承该设置 - Node.js：默认已忽略
SIGPIPE，但若使用child_process.spawn()创建子进程，需显式配置{ stdio: 'pipe' }并监听error事件
忽略 SIGPIPE 后，write() 返回 EPIPE 就万事大吉？
不。忽略 SIGPIPE 只是让进程不死，但 write() 仍会失败并返回 -1、errno = EPIPE。如果代码没检查这个错误，就会静默丢弃数据、卡住连接或引发后续逻辑异常。
关键检查点：
- 所有阻塞式写操作后，必须判断返回值：
if (n == -1 && errno == EPIPE)，然后关闭 fd、清理连接、记录告警 - 使用
send(..., MSG_NOSIGNAL)（Linux 特有）可绕过SIGPIPE生成，但移植性差，不如统一忽略 + 错误检查 - 协程/异步框架（如 Swoole、uvloop）中，I/O 调用可能封装了重试逻辑，但仍需确认其对
EPIPE的处理策略——有些框架会抛出异常，有些则静默吞掉
最易被忽略的是：信号忽略设置必须在任何 I/O 操作之前完成，且不能被子进程或动态加载模块覆盖。一次漏设，整个服务就暴露在 SIGPIPE 的秒杀风险下。
