cpu密集型用进程池，i/o密集型用线程池，混合型需分层组合；进程绕过gil实现多核并行，线程在i/o时释放gil提升并发，异步方案适用于超高并发i/o场景。
进程池和线程池不是“选一个就好”，而是要根据任务类型、资源瓶颈和 python 的 GIL 特性来决定——CPU 密集型用进程池，I/O 密集型用线程池，混合型可组合使用。
CPU 密集型任务：优先用 进程池（multiprocessing.Pool）
Python 的全局解释器锁（GIL）会阻止多线程真正并行执行 CPU 计算。哪怕开了 10 个线程，同一时刻也只有一个在跑 CPU 运算，其余等待。进程则绕过 GIL，每个进程有独立解释器和内存空间，能充分利用多核。
- 典型场景：图像批量处理、科学计算（numpy 矩阵运算）、加密解密、数据压缩、模型推理（非框架优化时）
- 注意点：进程间通信开销大，不适合频繁传递大量数据；启动进程比线程重，小任务反而更慢
- 建议：进程数通常设为 os.cpu_count() 或略高（如 +1），避免过度创建
I/O 密集型任务：优先用 线程池（concurrent.futures.ThreadPoolExecutor）
当任务大部分时间在等网络响应、磁盘读写、数据库查询或文件操作时，GIL 会在 I/O 阻塞时自动释放，其他线程就能接着运行。线程轻量、启动快、共享内存方便，适合高频调度小任务。
- 典型场景：爬虫并发请求、批量调用 API、日志写入、CSV/json 文件读写、数据库批量插入（连接池配合下）
- 注意点：线程不解决 CPU 瓶颈；若任务中混入较多计算，可能拖慢整体响应
- 建议：线程数可设得较高（如 20–100），具体看 I/O 延迟和系统连接限制，不必严格匹配 CPU 核数
现代替代方案：asyncio + aiohttp / aiosqlite 更适合高并发 I/O
对于万级 HTTP 请求或实时消息处理，线程池仍有上下文切换和内存占用问题。异步 I/O 在单线程内通过事件循环调度协程，资源效率更高。
立即学习“Python免费学习笔记（深入）”；
- 适用前提：所有依赖库需支持 async（如 aiohttp 替代 requests，aiomysql 替代 pymysql）
- 不适用情况：无法改写为 await 的同步库（如某些 C 扩展）、含阻塞调用（time.sleep、普通 open）需用 asyncio.to_thread 包装
- 提醒：async 不是万能加速器，错误使用（如 await 太少或太多）反而降低性能
混合场景：分层处理，各司其职
真实项目常同时存在计算与 I/O：比如下载图片（I/O）→ 调整尺寸（CPU）→ 保存到磁盘（I/O）。硬套单一池子会低效。
- 推荐模式：用线程池做下载和存储，把耗 CPU 的缩放交给进程池处理；或用 asyncio 下载，再用 multiprocessing.Process 单独处理关键计算
- 数据传递：用 Queue、Pipe 或临时文件中转，避免 pickle 序列化大对象（如 ndarray）带来的性能损失
- 调试提示：用 psutil 查看实际 CPU 和 I/O 使用率，比“感觉慢”更可靠