time.sleep()会冻结整个线程导致asyncio事件循环瘫痪，因其不主动让出控制权；而await asyncio.sleep()是协作式等待，将协程挂起并交还控制权给事件循环。
因为 time.sleep() 会冻结整个线程，包括事件循环本身，导致所有协程、IO、定时器全部停摆——这不是“延迟”，是硬卡死。
为什么 time.sleep() 会让 asyncio 彻底瘫痪
asyncio 的并发靠单线程内协作式调度：每个协程必须主动 await 让出控制权，事件循环才能切到下一个任务。time.sleep() 不让出、不通知、不挂起，它直接调用操作系统级休眠，把整个线程（含事件循环）钉在原地。
- 现象：一个
time.sleep(3)执行期间，asyncio.create_task()启动的其他协程完全不运行 - 连
asyncio.sleep(0.001)都能触发调度，但time.sleep(0.001)仍会阻塞至少一个调度周期 - 常见误判：以为“只睡 1 毫秒影响不大”，实际可能阻塞后续多个 ready 协程的执行窗口
await asyncio.sleep() 到底做了什么
它不是“异步版 time.sleep()”，而是一个显式注册到事件循环的等待点：
提示词大师-python版
下载
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 调用时立即返回，当前协程进入
suspended状态，控制权交还给事件循环 - 事件循环继续轮询其他任务、处理 socket 就绪、执行回调
- 到期后，该协程被重新标记为
ready，等待下一次调度 - 参数支持浮点数（如
await asyncio.sleep(0.05)），但精度受事件循环负载影响，不保证严格准时
哪些地方最容易偷偷混进 time.sleep()
不是只有主函数里明写才危险，这些位置更隐蔽：
- 日志重试逻辑：比如在
async函数里写if failed: time.sleep(1); retry() - 第三方同步库封装层：有人把
requests.get()包进async函数却忘了用run_in_executor，顺手加time.sleep()控制频率 - 测试脚本里：直接在 REPL 或普通脚本中写
await asyncio.sleep(1)却没包在async def里，报错模糊（RuntimeError: no running event loop），转头就换回time.sleep()应急 -
async for循环体内：例如逐行读取aiofiles时，在每行后插time.sleep(0.1)限速，结果异步流退化成串行，吞吐归零
真没法异步怎么办？别硬扛
遇到必须调用的同步阻塞函数（如某些本地计算、老 SDK、subprocess.run()），正确解法不是忍着用 time.sleep()，而是明确剥离：
- 用
loop.run_in_executor(None, blocking_func, *args)丢进默认线程池 - 若需控并发数，显式传
ThreadPoolExecutor(max_workers=3) - CPU 密集型任务换
ProcessPoolExecutor，否则线程池反而挤占事件循环资源 - 绝对不要在
run_in_executor里传lambda或闭包引用大对象，容易内存泄漏
真正麻烦的从来不是“不知道怎么改”，而是整个外层函数必须声明为 async def，调用链上游也得跟着改——漏掉一层，就全白搭。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
