ThreadPoolExecutor.submit()提交的任务异常不会自动抛出，必须显式调用result()或exception()才能捕获；as_completed()可安全遍历完成的Future并及时处理异常，而map()默认不传播异常且无超时控制。
ThreadPoolExecutor.submit()提交的任务异常不会自动抛出
直接调用 submit() 后不显式检查结果，线程里发生的异常会被静默吞掉，主线程完全感知不到。这不是 bug，是设计使然：Future 对象把异常封装在内部，等着你主动取。
常见错误现象：submit() 返回后程序正常退出，但实际某个任务已因 KeyError 或 ConnectionError 失败，日志里还找不到痕迹。
- 必须对每个
Future调用result()或exception()才能触发出错逻辑 -
result(timeout=...)会阻塞并抛出原始异常（如ZeroDivisionError），适合需要失败即停的场景 -
exception()非阻塞，返回异常对象或None（无异常时），适合批量检查
用as_completed()安全遍历所有完成的Future并捕获异常
比起手动循环调用 result()，as_completed() 更自然：它按完成顺序 yield Future，避免等待慢任务拖累快任务的结果处理。
使用场景：多个网络请求、文件处理等耗时不均的任务，既要及时响应成功项，也要不漏掉任一异常。
立即学习“Python免费学习笔记（深入）”；
from concurrent.futures import ThreadPoolExecutor, as_completed
<p>def risky_task(x):
if x == 2:
raise ValueError("x cannot be 2")
return x * x</p><p>with ThreadPoolExecutor() as executor:
futures = [executor.submit(risky_task, i) for i in [1, 2, 3]]
for f in as_completed(futures):
try:
res = f.result() # 这里才真正抛异常
print("success:", res)
except ValueError as e:
print("caught:", e)
注意：as_completed() 不保证提交顺序，也不保证所有 future 都已完成才开始遍历 —— 它只等第一个完成就 yield。
map()方法默认不传播异常，需配合timeout或手动包装
executor.map(func, iterable) 看似简洁，但它在遇到首个异常时就停止迭代，并把异常延迟到你遍历返回的 iterator 时才抛出。这容易误判为“只失败了一个”，其实后续任务根本没执行。
- 它底层是按顺序 submit + 按顺序 result()，不具备并发性优势
- 没有内置 timeout 控制单个任务，超时会卡住整个 map 迭代
- 若需异常中断+超时，推荐改用
submit()+as_completed()组合
如果坚持用 map()，务必用 try/except 包裹迭代过程：
try:
for result in executor.map(risky_task, [1, 2, 3]):
print(result)
except ValueError as e:
print("map stopped at first error:", e)
未处理的异常会滞留在Future中，直到被显式消费
这是最容易忽略的一点：只要你不调用 result() 或 exception()，哪怕线程已崩溃，Future 对象也不会释放异常，更不会影响进程退出。Python 不会帮你“兜底”。
后果：线上服务长期运行时，大量失败的 Future 积压，内存缓慢增长；排查时发现“任务没反应”，却查不到报错。
- 务必在任务生命周期内完成
result()或exception()调用 - 使用
wait()只是等完成状态，不提取异常，不能替代result() - 若任务可丢弃，至少调用一次
exception()做空检查，避免异常驻留
