异步框架通过单线程事件循环调度协程，避免线程空转和上下文切换开销，在io等待时立即切换任务，显著提升qps；关键在于整条异步生态链协同，而非仅用async/await，任一同步调用都会阻塞事件循环。
因为异步框架用单线程事件循环调度协程，避免线程空转和上下文切换开销，IO等待期间立刻切走执行其他任务——这在大量HTTP调用、数据库查询、服务间通信等场景中，直接把QPS拉高数倍。
asyncio事件循环怎么避免线程空转
同步模型下，requests.get()一发出去，线程就卡住干等；100个并发请求 = 100个线程挂起在S状态，CPU空转，内存暴涨。而asyncio的事件循环不靠抢资源，靠“不浪费等待时间”：一个协程await网络响应时，立刻切到另一个已就绪的协程（比如刚收到的HTTP响应、或文件读完的信号）。这个切换在用户态，开销约1μs；线程切换要进内核，动辄3–5μs——1000次调度下来，差出几毫秒，就是几百QPS的差距。
为什么光写async def没用
真正起作用的是整条异步生态链，不是单个async/await。常见踩坑点：
-
aiohttp必须替代requests，否则requests.get()会直接卡死整个事件循环 - 数据库要用
asyncpg或aiomysql，且连接池设autocommit=True，否则cursor.execute()漏await就返回协程对象，后续逻辑崩得无声无息 - 文件操作不能直接
open()，得用aiofiles或asyncio.to_thread()包装 - 日志避开
logging.FileHandler这类阻塞式写入，否则某次刷盘慢了，整条请求链就被拖住
asyncio.sleep()和time.sleep()在微服务里是两种生物
很多团队把同步代码“伪异步化”：用time.sleep(1)模拟耗时，再套async def，结果协程根本没并发，还是串行跑。因为time.sleep是操作系统级阻塞，整个线程停住；asyncio.sleep是协程级挂起，控制权立刻交还给事件循环。后果很实际：
- 控制节奏，能比
time.sleep(0.1)多处理3倍以上请求 - 健康检查接口若用了
time.sleep，一个3秒超时就拖垮整批检查 -
FastAPI依赖注入里混进time.sleep，整个请求生命周期都会被卡住
asyncio.gather不是万能并发开关
asyncio.gather和asyncio.create_task都能并发，但行为差异极大：
-
asyncio.gather(*tasks)是“全成功才返回”，任一子协程抛异常（比如下游服务503），整个gather就中断，其他还在跑的任务全被cancel——适合强一致性聚合场景，但不适合松耦合微服务调用 -
asyncio.create_task是独立调度，失败不影响其他任务，适合后台保活类逻辑（如定期刷新缓存、上报心跳） - 服务网关做API聚合时，若用
gather并发调下游，一个节点抖动会导致整条响应失败；换成create_task+手动await更稳
真正难的不是写async，是让整个调用链路都非阻塞——从HTTP客户端、DB驱动、文件读写，到日志、配置加载、甚至第三方SDK，任何一处漏掉await或混入同步调用，都会让事件循环卡住，性能优势瞬间归零。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
