应优先使用ThreadPoolExecutor处理I/O密集型任务，因其自动管理线程生命周期、支持超时取消及Future结果查询；CPU密集型任务则用ProcessPoolExecutor；map适用于同函数多参数批量调用，submit更灵活可配参和超时；需显式检查Future异常避免静默失败。
直接用 concurrent.futures.ThreadPoolExecutor 就行，它把线程创建、任务分发、结果收集全包了，比手动管理 threading.Thread 少写 70% 的胶水代码。
什么时候该用 ThreadPoolExecutor 而不是 threading？
当你需要并发执行多个 I/O 密集型任务（比如发 HTTP 请求、读写文件、调数据库），且不想自己维护线程生命周期时，ThreadPoolExecutor 是更安全的选择。
- 手动开
threading.Thread容易漏掉join()或忘记异常捕获，导致主线程提前退出或资源泄漏 -
ThreadPoolExecutor自动复用线程、统一回收、支持超时和取消，submit()返回的Future对象能随时查状态或取结果 - 如果任务是 CPU 密集型，优先考虑
ProcessPoolExecutor，否则 GIL 会让多线程几乎没提速
map() 和 submit() 怎么选？
map() 适合“同一种函数 + 多组参数”的批量调用；submit() 更灵活，支持不同函数、带额外参数、按需控制执行顺序。
-
map()返回的是迭代器，结果顺序与输入顺序严格一致，但无法单独为某个任务设超时 -
submit()返回单个Future，可配合as_completed()实现“谁先完成谁先处理”，适合响应时间差异大的场景 - 示例：
executor.map(requests.get, urls)简洁；但若要对每个 URL 加不同 headers，就得用submit(requests.get, url, headers=...)
常见错误：忘记处理 Future.exception() 或超时
任务出错不会自动抛到主线程，不显式检查 Future 状态就可能静默失败。
立即学习“Python免费学习笔记（深入）”；
- 调用
result()会阻塞并重新抛出原始异常；用exception()可非阻塞判断是否出错 - 不设
timeout参数的话，result()可能永远卡住——尤其网络请求没配requests.timeout时 - 别在循环里反复调
submit()后立刻result()，这等于串行执行；应先 collect 所有Future，再统一as_completed()或map()
真正麻烦的是混合 I/O 和 CPU 操作的场景——比如下载完文件立刻做图像处理。这时候得拆成两层 executor，或者改用 asyncio 配合 loop.run_in_executor，否则线程池容易被 CPU 任务拖慢。
