brokenpipeerror常被忽略或导致崩溃，因其继承自oserror而非exception，裸except无法捕获；且print内部可能触发systemexit，使try/except失效。应显式捕获并调用os._exit(0)静默退出，避免二次i/o错误。
为什么BrokenPipeError经常被忽略或导致程序崩溃
Python 默认在写入已关闭的管道（比如 head -n 1 提前退出时）时抛出 BrokenPipeError，但这个异常继承自 OSError，不是 Exception 的直系子类，所以用裸 except: 或 except Exception: 都捕获不到。更麻烦的是，Python 在标准输出/错误流上遇到该错误后，还可能触发 SystemExit（尤其在 print() 内部），让程序直接退出，连 try/except 都来不及生效。
正确捕获BrokenPipeError的两种方式
最稳妥的做法是显式捕获 BrokenPipeError，并配合 os._exit(0) 快速退出，避免后续清理逻辑再触发 I/O 错误。注意不能用 sys.exit()，它会再次尝试 flush 输出流，可能二次报错。
- 对单次输出：用
try/except BrokenPipeError:包裹print()或sys.stdout.write() - 对整个程序：在入口处用
try/except包住主逻辑，并在捕获后调用os._exit(0) - 如果使用
logging模块输出到 stdout/stderr，需提前设置handlers的stream并手动处理其write()方法异常
示例：
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
import sys
import os
try:
for i in range(1000):
print(i)
except BrokenPipeError:
os._exit(0)
使用signal.SIGPIPE拦截是否可行
不可行。Python 默认将 SIGPIPE 设为 SIG_DFL，但 C 层 write 系统调用收到 SIGPIPE 后直接终止进程，Python 的 signal handler 来不及介入。即使你用 signal.signal(signal.SIGPIPE, signal.SIG_IGN)，也仅对 Python 主动调用 os.kill() 等场景有效，对底层 write 失败无用。所以别碰 SIGPIPE，老实用 try/except BrokenPipeError。
管道破裂常出现在哪些真实场景
典型场景包括：脚本输出被 head、grep -m1、less（用户按 q 退出）、CI 日志截断工具消费；Docker 容器中 stdout 被重定向到已关闭的 socket；Jupyter notebook kernel 断开后仍尝试 print。这些情况下，你的程序不是“出错了”，而是“消费者走了”，应静默退出，而非打印 traceback。
容易被忽略的一点是：Python 3.2+ 在 sys.stdout 关闭后调用 print() 会先 raise ValueError: I/O operation on closed file，这和 BrokenPipeError 是两回事——得同时处理这两种异常，尤其在做流式输出工具时。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
