子进程异常不会自动冒泡至主线程，需显式调用future.result()才能获取原始错误；传参须可序列化，避免闭包和不可序列化对象；子进程堆栈需手动捕获打印。
子进程里抛的异常根本不会冒泡到主线程
ProcessPoolExecutor 默认把子进程的异常吞掉，只返回一个 BrokenProcessPool 或直接卡死，根本看不到原始错误信息。这不是 bug，是 multiprocessing 的设计使然——子进程崩溃后，主进程只能感知“连接断了”，没法自动反序列化异常对象。
常见错误现象：concurrent.futures.process.BrokenProcessPool、任务突然静默失败、result() 阻塞不返回。
- 必须显式调用
future.exception()或future.result()（后者会重新抛出异常）才能拿到子进程里的真实错误 - 别在提交任务后不检查结果就继续往下走，否则异常会一直被压着
- 如果用
as_completed()或map()，异常依然要靠每个Future单独捕获
用 result() 捕异常比 try/except future.exception() 更直接
future.exception() 返回的是异常实例（可能为 None），而 future.result() 在异常发生时会原样 re-raise——这对调试更友好，堆栈也完整。
使用场景：批量提交后统一收集结果，或单个任务需强错误反馈。
立即学习“Python免费学习笔记（深入）”；
-
future.result()会阻塞直到完成，适合你明确需要等结果的场景 - 如果想非阻塞检查，才用
future.exception()，但要注意它返回None表示还没完成，不是没异常 - 别对同一个
Future反复调result()，第二次会直接抛异常（即使第一次已处理）
for future in futures:
try:
res = future.result() # 这里才会真正抛出子进程里的 ValueError
except ValueError as e:
print(f"子进程出错了：{e}")子进程中不能用闭包引用不可序列化的对象
ProcessPoolExecutor 底层靠 pickle 传参，所有传入函数和参数都得能被序列化。常见翻车点：lambda、嵌套函数、带文件句柄/数据库连接/线程锁的对象。
错误信息典型长这样：AttributeError: Can't pickle local object 'xxx' 或 PicklingError。
- 函数必须定义在模块顶层，不能是类方法（除非用
functools.partial显式绑定且 self 可序列化） - 避免传
self、sys.stdout、logging.getLogger()这类运行时对象 - 路径、字符串、数字、纯数据结构（dict/list/tuple）安全；
datetime、numpy.ndarray多数情况也 OK，但别传自定义类实例
异常堆栈默认不包含子进程源码位置
即使捕获到了异常，堆栈最深一层往往停在 concurrent.futures.process._process_worker，你看不到自己代码哪行出了问题。
原因：子进程 worker 是通用入口，原始 traceback 被截断了。
- 加一句
import traceback; traceback.print_exc()在子进程函数内部，能强制打出完整堆栈到子进程 stdout（注意主进程可能收不到，得重定向） - 更稳的做法：在子进程函数里用
try/except包住逻辑，把traceback.format_exc()当字符串返回，主进程再打印 - 别依赖 IDE 的断点调试子进程——multiprocessing 的子进程无法被常规 debug 模式 attach
子进程异常本身不可跨进程传播，能做的只有“主动拉取”和“提前防住”。最常被忽略的是：以为 submit 后异常会自动冒泡，结果日志空空如也，排查半小时才发现根本没调 result()。
