线程池max_workers应按任务类型设定：i/o密集型20–100，cpu密集型≤os.cpu_count()，混合场景优先i/o压力；需显式shutdown、设超时、捕获异常、避免result()串行阻塞。
ThreadPoolExecutor 创建时 max_workers 设多少才不翻车
线程池不是越大越好，设太高反而触发 GIL 争抢、内存暴涨，甚至被系统 kill。默认值是 min(32, os.cpu_count() + 4)，但这对 I/O 密集型任务偏保守，对 CPU 密集型又偏激进。
实操建议：
- I/O 密集（如 http 请求、文件读写）：设
20–100，取决于并发请求延迟和连接池大小，别盲目堆到几百 - CPU 密集（如数值计算、图像处理）：严格限制在
os.cpu_count()或更低，多开线程不会加速，只会增加上下文切换开销 - 混合场景（比如先请求再本地处理）：优先按 I/O 压力设，但用
concurrent.futures.as_completed避免阻塞等待 - 动态调整？别硬编码——用环境变量或配置项传入，上线后靠监控（如
threading.active_count()+ 日志）反推真实负载
submit() 和 map() 的行为差异导致结果顺序错乱
submit() 返回 Future 对象，调用顺序和完成顺序无关；map() 虽然按输入顺序返回结果，但底层仍是并发执行，且不支持带关键字参数的函数。
常见错误现象：
立即学习“Python免费学习笔记（深入）”；
- 用
list(executor.map(func, items))得到结果，却发现某次运行里第 3 个结果对应的是第 7 个输入——其实是map()本身保序，但如果你用了自定义的包装函数漏传参数，就会错位 - 想用
submit()后统一收集结果，却直接对Future列表调result()，导致串行等待，完全失去并发意义
实操建议：
- 要保序且简单调用：用
executor.map(func, items)，但确保func是纯函数，无副作用 - 要灵活控制（如超时、异常分类、部分失败继续）：用
submit()+as_completed(futures)，别用wait() - 带关键字参数？别硬套
map()——改用submit(func, *args, **kwargs)或预绑定functools.partial
未正确处理异常导致主线程静默失败
Future.result() 不显式调用就不会抛出子线程里的异常，而 submit() 本身从不报错。很多代码只管提交，忘了检查 future.exception() 或没包 try/except 在 result() 外层。
典型表现：
实操建议：
- 每个
future.result(timeout=...)必须包try/except Exception as e:，至少 log.Error(e) - 批量处理时，用
future.exception()先判断是否有错，避免调result()时卡住（尤其设了 timeout） - 别依赖
__exit__自动 shutdown——显式调executor.shutdown(wait=True)，否则可能丢掉还没来得及抛出的异常
长时间运行任务卡死线程池无法回收
线程池里的线程一旦开始执行任务，就不会主动中断。如果某个 func 卡在死循环、无限重试、或阻塞 I/O（如没设 timeout 的 requests.get()），那个线程就永远占着，max_workers 会慢慢被耗尽。
这不是线程池 bug，是使用者没设防。
实操建议：
- 所有外部调用必须加超时：
requests.get(url, timeout=(3, 7))、time.sleep()前检查退出条件、数据库查询设command_timeout - CPU 密集任务加心跳检测：用
threading.local()记录开始时间，定期检查是否超限，主动 raise - 别指望
shutdown(wait=False)能杀线程——python 没提供安全强制终止线程的机制，只能靠任务自己响应中断信号 - 真正需要“可取消”？换
asyncio.to_thread()（Py3.9+）或进程池ProcessPoolExecutor，但代价是序列化开销
线程池不是黑盒，它暴露的每个接口都在暗示你：谁启动、谁清理、谁负责超时、谁兜底异常。漏掉任意一环，问题都会藏在深夜三点的日志碎片里。