Python并发架构演化核心是高效利用I/O等待时间：同步阻塞受限于线程/进程资源；多线程/多进程绕过GIL但扩展性差；asyncio通过事件循环实现单线程高并发；混合架构兼顾现实场景的异步主干与同步隔离。
Python并发架构的演化，核心是围绕“如何更高效地利用I/O等待时间”展开。由于CPython的GIL限制，多线程无法真正并行计算，但I/O密集型场景下，通过让出控制权、复用单线程资源，反而能支撑高并发——这是整个演化的出发点。
同步阻塞：最直白，也最受限
传统requests.get()或time.sleep()会卡住整个线程，一个请求没返回，后续任务只能干等。适合脚本、低QPS工具，但无法应对数百并发连接。
- 每并发1个请求，就占1个线程（或进程），资源开销线性增长
- 系统级线程切换成本高，Linux默认线程栈2MB，1000并发≈2GB内存
- 没有超时、重试、连接池等生产级保障，容易雪崩
多线程/多进程：绕过GIL，代价明确
用threading处理I/O等待，用multiprocessing跑CPU密集任务。虽能提升吞吐，但模型仍是“一个任务配一个执行单元”，扩展性有限。
- 线程数建议≤CPU核心数×2～4，过多反而因上下文切换拖慢整体响应
- 进程间通信需Queue或Pipe，共享状态要加锁，复杂度陡增
- 启动慢、内存占用大，不适合短生命周期高频任务（如API网关）
异步IO（asyncio + await）：单线程高并发基石
用事件循环调度协程，遇到I/O自动挂起、就绪后恢复，把“等待时间”变成“处理其他请求的时间”。典型代表是aiohttp、fastapi底层。
立即学习“Python免费学习笔记（深入）”；
- 所有I/O操作必须用异步库（aiomysql而非pymysql）
- 不能在async函数里调用同步阻塞代码（如time.sleep(1)），否则整个事件循环卡死
- 调试难度上升：堆栈含协程帧，错误定位需熟悉Task和Future状态
混合架构：现实系统的常见解法
纯异步难覆盖全部场景（如调用某些C扩展、遗留同步SDK），于是出现“异步主干+同步隔离”的混合模式。
- 用loop.run_in_executor()把耗时同步操作扔进线程池，避免阻塞事件循环
- Web层用FastAPI（async），数据处理模块用Celery（multiprocess）做离线任务
- 关键路径保持异步，非关键路径（如日志上报、指标采集）降级为后台线程或队列异步推送
不复杂但容易忽略：选型不是越新越好，而是看瓶颈在哪。I/O多？上asyncio。CPU重？上multiprocessing。混合负载？分层拆解，各司其职。
