multiprocessing.pipe默认为全双工，但若未明确区分读写端并同步关闭写端，主线程recv会因无数据而永久阻塞；需用duplex=false明确分工、加timeout、子进程结束前close写端以触发eoferror。
为什么 multiprocessing.Pipe 不能直接在主线程里 recv 而不 send？
因为 Pipe 默认创建的是**半双工连接**（除非显式传 duplex=True），且两端都阻塞等待数据。如果你只在子进程 send，而主线程没调用 recv，子进程的 send 可能卡住——尤其当缓冲区满或对方未就绪时。更常见的是：主线程调用 recv 但子进程还没来得及 send，结果主线程永久阻塞。
实操建议：
- 始终用
duplex=False明确区分读/写端（推荐）：子进程用wr端send，主进程用rd端recv - 加超时避免死锁：
rd.recv(timeout=2)，捕获EOFError或BrokenPipeError - 子进程结束前务必
close()写端，否则主进程recv可能永远等不到 EOF
如何安全地在多进程中传递复杂对象（如 dict、list）？
Pipe 底层依赖 pickle 序列化，所以能传大多数内置类型和可 pickle 的自定义类实例。但要注意边界：
常见错误现象：TypeError: cannot pickle '_thread.RLock' object —— 传了带线程锁、文件句柄、生成器等不可序列化对象。
实操建议：
- 只传纯数据结构：
dict、list、tuple、int、str、None，或明确实现__getstate__/__setstate__的类 - 避免传
lambda、嵌套函数、模块对象（如os）、打开的file对象 - 大对象（>10MB）慎用：
Pipe是内存拷贝，不是共享内存，会触发完整序列化+反序列化开销
子进程崩溃时，Pipe 的另一端会发生什么？
子进程异常退出（未正常 close() 写端）后，主进程调用 recv() 会立即抛出 EOFError（如果已读完）或 BrokenPipeError（若尝试 send 到已关闭的端）。但更隐蔽的问题是：主进程可能卡在 recv() 上，等一个永远不会来的消息。
实操建议：
- 用
Process.is_alive()在recv前做兜底检查 - 对关键通信加
try/except (EOFError, BrokenPipeError, OSError)捕获 - 子进程逻辑末尾强制
wr.close()，并在finally块中确保执行 - 不要依赖
rd.poll()判断“是否有数据”——它只反映内核缓冲区状态，不保证数据可安全反序列化
Pipe 和 Queue 在测试场景下怎么选？
测试中选 Pipe 的核心理由是：**点对点、低延迟、可控流控**。比如验证两个进程间严格的一问一答协议，或模拟硬件串口通信行为。而 Queue 是多生产者/多消费者模型，内部带锁和缓冲队列，额外开销明显，且无法精确控制哪条消息来自哪个子进程。
实操建议：
- 一对一通信（如 worker ↔ monitor）、需要精确顺序、要求最小延迟 → 用
Pipe - 一对多广播、需支持多个接收者、要内置线程安全 → 用
Queue - 测试中想快速复现竞争条件？
Pipe更敏感：少一个close()就卡死，比Queue更容易暴露资源管理漏洞
真正难处理的不是语法，而是子进程生命周期和 Pipe 端状态的耦合——关早了，主进程收不到；关晚了，主进程不知道该不该等。这个边界必须手动对齐，没有自动机制兜底。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
