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() 拖慢响应
