ThreadPoolExecutor 比 threading.Thread 更省心，因其自动管理线程生命周期、复用、回收及异常传播，避免手动维护线程列表、调用 join() 或遗漏子线程异常；适用于 I/O 密集型任务，不适用 CPU 密集型场景。
为什么 ThreadPoolExecutor 比直接 threading.Thread 更省心
因为 ThreadPoolExecutor 自动处理线程创建、复用、回收和异常传播，你不用手动维护 threading.Thread 列表、调用 join()、或担心未捕获异常让线程静默退出。
常见错误现象：手动启一堆 threading.Thread 后忘记 join()，主线程提前退出；或异常发生在子线程里，主程序完全无感知。
- 使用场景：I/O 密集型任务（如 HTTP 请求、文件读写、数据库查询）
- 不适用场景：CPU 密集型任务（应优先考虑
ProcessPoolExecutor） -
max_workers设为None时，Python 默认设为min(32, (os.cpu_count() or 1) + 4)—— 这个值对 I/O 任务通常偏保守，可按实际并发需求调高（比如 20~100）
submit() 和 map() 的核心区别与选法
submit() 返回单个 Future 对象，适合任务参数差异大、需单独控制超时或结果顺序；map() 批量提交同函数多参数，自动保持输入顺序并阻塞等待全部完成。
容易踩的坑：map() 不支持传入关键字参数，且一旦某个任务抛异常，整个 map() 调用会立即中断（不像 submit() + as_completed() 可逐个检查）。
立即学习“Python免费学习笔记（深入）”；
- 用
submit()：需要异步触发、后续再统一result(timeout=5)或用as_completed()处理返回值 - 用
map()：参数是简单可迭代对象（如列表），函数无副作用，且你能接受“全成功才继续” - 性能影响：对大量小任务，
map()内部做了批量优化，比循环调用submit()略快；但灵活性差很多
如何安全获取结果并处理超时/异常
Future.result() 是阻塞调用，不加 timeout 可能永远卡住；而未显式调用 result() 或 exception()，异常会被吞掉 —— 这是生产环境最常被忽略的问题。
示例中常见错误写法：executor.submit(task).result() 在循环里直接调用，等于退化成串行执行。
- 正确做法：先
submit()全部任务，再统一用as_completed(futures)遍历，每个调用future.result(timeout=10) - 捕获异常：在
try/except中调用result()，捕获concurrent.futures.TimeoutError和具体业务异常（如requests.RequestException） - 不要依赖
future.done()判断是否完成后再取结果 —— 它只表示“已结束”，不代表没异常；必须调用result()或exception()才能暴露异常
with 语句关闭线程池的必要性
不加 with 或不显式调用 shutdown(wait=True)，可能导致主线程退出时工作线程被强制终止，正在运行的任务中途丢弃、资源未释放（比如文件句柄、连接未 close）。
注意：wait=False 会让 shutdown() 立即返回，但不等任务结束 —— 这在脚本结尾用基本等于没关。
- 推荐始终用
with concurrent.futures.ThreadPoolExecutor(...) as executor: - 如果无法用
with（比如类成员变量），务必在生命周期结束前调用executor.shutdown(wait=True) - 极端情况（如 SIGINT 中断）下，
with仍可能来不及执行__exit__，可在信号处理器里补一层shutdown
线程池本身不难，难的是把异常流、资源释放、取消逻辑和超时边界都兜住 —— 这些地方一漏，问题往往延迟暴露，排查成本远高于写的时候多加三行代码。
