Queue.get()无法获取子进程异常，因multiprocessing.Queue不序列化传递异常对象；需手动封装Result或字典结构传递错误信息，主进程再解析并raise。
为什么Queue.get()拿不到子进程抛出的异常
Python 的 multiprocessing.Queue 默认不会自动序列化并传递异常对象——它只传数据，不传「崩溃现场」。子进程里未捕获的异常会导致进程静默退出，主进程在 get() 时可能卡住、超时，或收到一个空/非法值，但绝不会自动 raise 出原始异常。
根本原因是：异常对象（如 ValueError 实例）跨进程需经 pickle 序列化，而很多异常类型（尤其自定义异常或带闭包/lambda 的）无法被安全 pickle；即便能，Queue 本身也不做「异常重抛」逻辑。
- 子进程中用
try/except捕获后，把repr(e)或traceback.format_exc()当字符串塞进Queue.put() - 更稳妥的做法是统一包装成字典：
{'error': True, 'type': 'ValueError', 'msg': 'xxx', 'tb': '...'} - 主进程
get()后先检查结构，再手动raise构造的异常（注意：只能 raise 内置或已导入的异常类）
用multiprocessing.Manager().Queue()也不能解决异常传递
Manager().Queue() 是代理对象，底层走的是进程间通信（IPC）服务器，它比原生 Queue 更慢，且同样不处理异常透传。它的优势是支持跨更多进程共享、可被嵌套在 dict/list 中，但「异常还是得自己打包」。
常见误判：以为 Manager 的 Queue 更“高级”，就能自动转发异常。实际测试会发现，子进程 crash 后，主进程调用 get() 可能阻塞或抛 EOFError/OSError，而非原始业务异常。
立即学习“Python免费学习笔记（深入）”；
- 不要依赖
Manager().Queue()自动传异常 - 若必须用 Manager，仍需手动封装错误信息 + 状态标记
- 注意 Manager 进程本身可能成为单点瓶颈，高吞吐场景慎用
推荐方案：子进程返回结果统一用Result容器
写一个轻量 Result 类（无需第三方库），让每个子进程都 put(Result(value=x)) 或 put(Result(error=e))，主进程统一解包判断。这样语义清晰、类型安全、易调试。
class Result:
def __init__(self, value=None, error=None):
self.value = value
self.error = error # 存 exception instance 或 str
def is_ok(self):
return self.error is None
def unwrap(self):
if self.error:
if isinstance(self.error, BaseException):
raise self.error
else:
raise RuntimeError(self.error)
return self.value
- 子进程里：
queue.put(Result(error=ZeroDivisionError("div by zero"))) - 主进程里：
r = queue.get(); r.unwrap()—— 成功则返回值，失败则原样 raise - 注意：若
error是 exception 实例，确保它可被pickle（避免含不可序列化字段）
容易忽略的边界：子进程 exit code 和 Queue.empty() 的误导性
Queue.empty() 在多进程下不可靠——它只是快照，无法反映其他进程是否刚 put 或即将 put。更糟的是，子进程异常退出后，其 exit code 可能为非零（如 1），但主进程若没显式 join() 或检查 p.exitcode，就完全感知不到。
- 永远不要用
queue.empty()作为「任务结束」信号 - 子进程完成前务必
put()一个 sentinel（如None）或Result标记 - 主进程应
join()所有子进程，并检查p.exitcode != 0作为兜底异常探测手段 - 对关键任务，建议加超时：
queue.get(timeout=30)，避免无限等待死锁
真正难的不是传异常，而是让主进程在各种退出路径（正常结束、异常崩溃、被 kill）下都能拿到一致、可操作的错误上下文。这需要在子进程封装层就设计好错误出口，而不是指望 IPC 机制替你补全。
