asyncio事件循环通过协程挂起与用户态切换避免线程空转：await时让出控制权，调度其他就绪协程，开销仅1μs；需全链路异步（aiohttp/asyncpg/aiofiles等），禁用time.sleep和阻塞I/O，合理选用gather或create_task。
asyncio 事件循环如何避免线程空转
同步模型下，requests.get() 或 conn.execute() 一调用，线程就卡住，CPU 干等，连接还占着不放。100 个并发请求 = 100 个线程在 sleep 状态排队，上下文切换猛、内存涨、系统调用多。而 asyncio 的事件循环不靠抢资源，靠“不浪费等待时间”：一个协程 await 网络响应时，立刻切走，去跑另一个已就绪的协程（比如刚收到的 HTTP 响应、或文件读完的信号）。这个切换在用户态，开销约 1μs；线程切换要进内核，动辄 3–5μs——1000 次调度下来，差出几毫秒，就是几百 QPS 的差距。
真正起作用的是整条异步生态链，不是单个 async/await
光写 async def 没用，必须整条链路非阻塞：
-
aiohttp替代requests，否则requests.get()会直接卡死整个事件循环 - 数据库用
asyncpg或aiomysql，且连接池要设autocommit=True，否则cursor.execute()漏await就返回协程对象，后续逻辑崩得无声无息 - 文件操作不能直接
open()，得用aiofiles或asyncio.to_thread()包装 - 连日志都得避开
logging.FileHandler这类阻塞式写入，否则某次刷盘慢了，整条请求链就被拖住
await asyncio.sleep() 和 time.sleep() 在微服务里是两种生物
很多团队把同步代码“伪异步化”：用 time.sleep(1) 模拟耗时，再套 async def，结果协程根本没并发，还是串行跑。因为 time.sleep 是操作系统级阻塞，整个线程停住；asyncio.sleep 是协程级挂起，控制权立刻交还给事件循环。后果很实际：
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 服务启动时批量注册 Consul 实例，用
await asyncio.sleep(0.1)控制节奏，能比time.sleep(0.1)多处理 3 倍以上请求 - 健康检查接口若用了
time.sleep，一个 3 秒超时就拖垮整批检查 - FastAPI 依赖注入里混进
time.sleep，整个请求生命周期都会被卡住，哪怕只有一处
asyncio.gather 不是万能并发开关，错误传播会放大故障
asyncio.gather 和 asyncio.create_task 都能并发，但行为差异极大：
立即学习“Python免费学习笔记（深入）”；
-
asyncio.gather(*tasks)是“全成功才返回”，任一子协程抛异常（比如下游服务 503），整个gather就中断，其他还在跑的任务全被 cancel —— 适合强一致性聚合场景，但不适合松耦合微服务调用 -
asyncio.create_task是独立调度，失败不影响其他任务，适合后台保活类逻辑（如定期刷新缓存、上报心跳） - 服务网关做 API 聚合时，若用
gather并发调下游，一个节点抖动会导致整条响应失败；换成create_task+ 手动收集结果，才能实现容错降级
