time.sleep() 会冻结整个事件循环线程，导致所有协程、任务、I/O 和定时器全部卡死；asyncio.sleep() 才是真正的协作式等待，它注册延迟回调、立即返回并让出控制权，支持并发等待且必须配合 await 使用。
time.sleep() 会直接冻结整个事件循环线程
它调用的是操作系统级休眠（如 nanosleep），不释放控制权给事件循环，而是让当前线程彻底挂起。而 asyncio 的事件循环就跑在这个线程里 —— 线程一停，循环就停，所有协程、asyncio.create_task() 启动的任务、网络读写、定时器全部卡死。
asyncio.sleep() 才是真正的协作式等待
asyncio.sleep() 不是“异步版 time.sleep()”，它本质是向事件循环注册一个延迟回调：调用后立即返回，当前协程进入 suspended 状态，事件循环继续轮询 socket 就绪、调度其他协程；到期后该协程被重新标记为 ready，等待下一次执行。
- 必须搭配
await使用，否则只得到一个未执行的coroutine对象 - 支持浮点数参数（如
await asyncio.sleep(0.05)），但精度受事件循环负载影响，不保证严格准时 - 最小可感知延迟约 1–5ms，低于这个值可能被合并或忽略
- 多个
await asyncio.sleep()可并发等待，总耗时取决于最长那个，而非累加
最容易偷偷混进 time.sleep() 的地方
错误往往不在主函数明写，而在这些边界场景：
- 把
requests.get()包进async def却没用loop.run_in_executor()，顺手加time.sleep()控制频率 → 整个服务吞吐归零 -
async for逐行读取aiofiles时，在每行后插time.sleep(0.1)限速 → 异步流退化成串行 - 测试脚本里写
await asyncio.sleep(1)却没包在asyncio.run()或async def main()里 → 报RuntimeError: no running event loop，转头换回time.sleep()应急 - 日志重试逻辑中：若这段代码在
async函数里，time.sleep()就全卡住
真没法异步怎么办？别硬扛
遇到必须调用的同步阻塞函数（如本地计算、老 SDK、subprocess.run()），正确解法是明确剥离，而不是在 async 函数里硬塞 time.sleep()：
立即学习“Python免费学习笔记（深入）”；
- 用
loop.run_in_executor()把阻塞调用扔进线程池 - Python 3.9+ 推荐用
asyncio.to_thread()替代，更简洁 - CPU 密集型任务慎用
asyncio.sleep(0)模拟让权 —— 它不能缓解 GIL 压力，纯属白忙
最常被忽略的一点：哪怕只 time.sleep(0.001)，也会阻塞至少一个调度周期，可能错过多个 ready 协程的执行窗口。协作式调度的前提是“主动让权”，不是“假装让权”。
