Python并发选型取决于任务类型：I/O密集型用asyncio或threading，CPU密集型必须用multiprocessing，混合场景可组合；需先判断任务性质，再依场景选择模型并注意GIL与资源隔离。
Python并发模型选型，核心是看任务类型：I/O密集型优先用asyncio或threading，CPU密集型必须上multiprocessing，混合场景可组合使用——没有银弹，只有匹配。
明确任务性质：I/O密集还是CPU密集？
这是选型的第一道分水岭。I/O密集型（如HTTP请求、数据库读写、文件读取）大部分时间在等响应，线程或协程切换开销小、收益高；CPU密集型（如数值计算、图像处理、加密解密）需要真并行，必须绕过GIL，靠多进程实现。
简单判断方法：
- 用time.time()测单任务耗时，再用psutil.cpu_percent()观察执行中CPU是否持续接近100% → 是CPU密集；
- 若大部分时间CPU占用低，但总耗时长 → 多为I/O等待 → 属I/O密集。
常见场景与推荐模型
- 高频HTTP调用（如爬虫、API聚合）：首选asyncio + aiohttp。协程轻量，万级并发内存友好；避免用requests+threading，线程创建销毁成本高，且易触发连接池瓶颈。
- 数据库查询为主（ORM操作、报表生成）：可用threading + connection pool（如SQLAlchemy的QueuePool），注意连接数上限需匹配线程数；异步驱动（如asyncpg、aiomysql）配合asyncio更优，但需DB支持。
- 图像批量缩放/视频转码：必须用multiprocessing，配合concurrent.futures.ProcessPoolExecutor管理进程；避免pickle大对象传参，改用共享内存（multiprocessing.shared_memory）或文件中转。
- Web服务中混杂逻辑（如FastAPI接口含DB查+调第三方+简单计算）：主线程用asyncio，CPU部分用loop.run_in_executor()扔给ProcessPoolExecutor，I/O部分直接await，不阻塞事件循环。
避坑要点：GIL、上下文与资源隔离
GIL不是“锁住所有代码”，而是解释器级互斥，只影响纯Python字节码执行；C扩展（如numpy矩阵运算、正则匹配）常会释放GIL，此时多线程也能提效——但不可依赖，需实测。
资源隔离关键点：
- threading：全局变量、模块级状态共享，需加锁（threading.Lock）；
- multiprocessing：进程间默认不共享内存，变量传递靠序列化，修改需用Manager或Value/Array；
- asyncio：协程共用同一线程上下文，无GIL争抢，但非线程安全，跨task共享状态仍需asyncio.Lock。
快速验证建议
- 先写单线程/单进程版本，作为性能基线；
- 用cProfile或py-spy record看热点，确认瓶颈在I/O等待还是CPU计算；
- 小规模试跑（如20并发/4进程），观察CPU、内存、IO wait指标变化；
- 生产前压测，重点关注连接泄漏（asyncio未close session）、进程僵死（multiprocessing子进程异常退出未捕获）、线程饥饿（threading中阻塞调用未超时）。
