Python并发架构演进重在务实权衡，需依IO类型选择同步线程池、多进程或asyncio：真IO密集用异步/线程，CPU密集用多进程/C扩展，伪IO须避免time.sleep误用。
Python并发架构的演进，核心不是追求“最新技术”，而是根据实际场景在可维护性、资源开销、IO特征和团队能力之间做务实权衡。从同步阻塞到async/await，路径清晰但并非线性升级——很多服务用好线程池+requests.session就足够，强行上异步反而增加调试成本。
明确IO类型：先分清是真IO密集，还是伪并发
Python的GIL对CPU密集型任务无效，但对网络IO、磁盘读写等系统调用友好。判断标准很简单：
- 用time.perf_counter()测单次请求耗时，若90%以上时间在wait（如socket.recv、os.read），属典型IO密集，适合异步或线程
- 若耗时集中在JSON解析、正则匹配、循环计算，则应优先考虑多进程或C扩展，而非asyncio
- 注意“伪IO”：比如用time.sleep(1)模拟延迟，它不释放GIL，线程无法并发，必须换asyncio.sleep(1)
选型不是越新越好：三种主流模式的适用边界
同步+线程池、multiprocessing、asyncio不是替代关系，而是分工关系：
- requests + ThreadPoolExecutor：适合中低QPS（
- multiprocessing：CPU密集且数据可序列化（如批量图像处理、数值计算）；注意进程启动开销大，不适合高频启停
- asyncio + httpx/aiohttp：高连接数、低延迟要求（如API网关、实时爬虫）；需全链路异步（DB驱动用asyncpg，缓存用aioredis），否则会在某处阻塞整个event loop
渐进式迁移：避免重写，优先封装阻塞点
已有同步代码不必推倒重来，可分层解耦：
立即学习“Python免费学习笔记（深入）”；
- 将阻塞操作（如数据库查询、HTTP调用）抽成独立函数，用loop.run_in_executor()包裹，让其在线程池中执行，主线程保持异步
- 用asynccontextmanager管理异步资源（如连接池），避免手动await close()遗漏
- 关键路径加asyncio.wait_for(task, timeout=...)，比同步timeout更精准——它能中断挂起的await，而非等待整个函数返回
监控与压测：别信理论值，要测真实瓶颈
并发性能永远受限于最慢环节，常见盲区：
- 数据库连接池大小是否匹配asyncio并发数？asyncpg默认pool_size=10，若并发100，90个协程会排队等待连接
- DNS解析是否阻塞？用aiodns替换系统getaddrinfo，避免event loop被卡住
- 日志写入是否同步？logging.handlers.QueueHandler配合后台线程，防止logger.info()拖慢响应
