submit()后异常不立即抛出，而是封存在Future中，需调用result()或exception()才暴露；as_completed()、wait()和map()返回的Future同样需显式获取结果才能触发异常处理。
concurrent.futures.Executor.submit() 后的异常不会立即抛出
调用 submit() 只是把任务放进线程/进程池，返回一个 Future 对象。异常被“捕获并封存”在 Future 里，直到你显式调用 result() 或 exception() 才暴露出来——这点和同步代码直觉相反，很多人卡在这儿。
- 不调
result()就永远看不到报错，任务失败了也像没发生一样 -
as_completed()和wait()返回的Future同样要手动取result()才会触发异常 - 如果多个任务并发，其中一个抛
ValueError，另一个抛TimeoutError，得分别处理，不能靠外层 try-except 拦住
用 result() + try/except 捕获单个 Future 异常最可靠
别信“统一 try 包整个 submit 循环”，那根本捕不到子任务异常。真正起作用的是对每个 Future 单独调 result() 并包一层 try/except。
-
result(timeout=5)会阻塞等待完成，并在超时或异常时抛出对应错误（TimeoutError或原始异常） - 想区分正常结果和异常？用
exception()先查有没有异常，有就处理，没就再调result()——但多一次判断，多数场景直接try/except result()更直白 - 注意：
result()抛出的是原始异常（比如ZeroDivisionError），不是BrokenProcessPool这类底层错误，除非进程池崩了
for future in futures:
try:
data = future.result() # ← 真正抛异常的地方
except ValueError as e:
print(f"数据格式错: {e}")
except Exception as e:
print(f"其他错: {e}")map() 模式下异常会延迟到遍历时才炸
Executor.map() 看起来像普通函数式调用，但它返回的是惰性迭代器。异常不会在 map() 调用时出现，而是在你 for 循环取值、或转成 list 时才逐个抛出。
- 写
list(executor.map(...))会一次性触发所有任务的异常，但你只能拿到第一个错——后面的还没走到，就被中断了 - 用 for 遍历 + try/except，才能逐个处理每个输入对应的异常，适合容错场景
-
map()不支持传timeout，想控制单个任务超时得换回submit()+as_completed()
ThreadPoolExecutor 和 ProcessPoolExecutor 的异常行为一致
两者都把异常封装进 Future，都靠 result() 暴露，这点完全统一。区别只在异常类型细节：
立即学习“Python免费学习笔记（深入）”；
- 进程池中函数内未捕获的异常，会被序列化传回主线程，类型不变（如
KeyError还是KeyError） - 但某些对象（比如带文件句柄、线程锁的实例）无法跨进程序列化，会抛
PicklingError，这属于配置错误，不是业务异常 - 线程池没序列化开销，但共享内存导致的竞态异常（如
RuntimeError: dictionary changed size during iteration）更难复现
实际用的时候，最常漏掉的是：忘了在 as_completed() 或 wait() 后对每个 Future 调 result()。异常就卡在那儿，程序看似跑完，其实一半任务静默失败了。
