time.sleep()会彻底冻结asyncio事件循环，导致所有协程、IO检查、定时器停摆；应改用await asyncio.sleep()或线程池执行同步阻塞操作。
time.sleep() 会彻底冻结 asyncio 事件循环
它不是“暂停当前协程”，而是让整个线程休眠——而 asyncio 的事件循环就跑在这个线程里。一旦执行 time.sleep(1)，所有正在运行或就绪的协程、IO 检查、定时器、心跳全部停摆，连刚用 asyncio.create_task() 启动的任务都不会执行一帧。
常见现象包括：
- 启动 10 个任务，其中 1 个写了
time.sleep(3)，其余 9 个会卡住整整 3 秒才开始调度 -
await asyncio.sleep(0.01)能触发一次调度，但time.sleep(0.01)仍阻塞至少一个完整调度周期，高负载下可能跳过多个 ready 协程 - FastAPI 或 aiohttp 接口响应变慢、超时、连接池耗尽，日志却无明显报错
哪些地方最容易偷偷混进 time.sleep()
危险位置往往不在主流程，而在逻辑胶水层，且错误提示模糊，容易被当作“临时方案”留下：
- 重试逻辑里：
while not success: do_request(); time.sleep(0.5)—— 整个异步流退化成串行 - 第三方同步库封装层：比如把
requests.get()包进async def，顺手加time.sleep()控频，结果拖垮服务吞吐 - 测试脚本或 REPL 中：
await asyncio.sleep(1)报RuntimeError: no running event loop，转头换成time.sleep(1)应急，却忘了环境根本没事件循环 -
async for循环体内：逐行读aiofiles时插time.sleep(0.1)，异步读取变成单行阻塞
asyncio.sleep() 不是“异步版 time.sleep”，而是调度契约
await asyncio.sleep(2.5) 的本质是向事件循环注册一个等待点：立即返回、协程挂起、控制权交还；2.5 秒后被重新标记为 ready 并排队等待下一次调度。它不保证严格准时，但保证不剥夺其他协程的执行机会。
SkillSub Pro - Python 题解与代码注释双功能技能功能概述SkillSub Pro - Python 题解与代码注释双功能技能是一项面向实际任务的技能，主要用于SkillSub Pro 是一个 Python 题解生成与代码注释的 双功能合体技能 ，专为学生、算法学习者和开发者设计；✅ 一个技能，两种用途 ：；核心要点📝 题解模式 ：输入题目/题号，自动生成完整 Python 题解（含详细注释、解题思路、复杂度分析）；💬 注释模式 ：输入 Python 代码，自动添加详细中。它将相关步骤、
立即学习“Python免费学习笔记（深入）”；
漏写 await 或在非 async 函数里调用，会触发不同层级的失败：
- 漏写
await：只得到一个<coroutine object asyncio.sleep at 0x...>，什么也不发生 - 在普通函数里调用：
RuntimeWarning: coroutine 'sleep' was never awaited - 没包进
asyncio.run()或手动启动事件循环：RuntimeError: no running event loop
真没法异步时，别硬套 asyncio.sleep()
遇到必须调用的同步函数（如老 SDK、本地计算、subprocess.run()），正确解法是剥离到线程池，而不是用 time.sleep() 掩盖问题：
- IO 类阻塞：用
loop.run_in_executor(None, blocking_func, *args) - 需控并发数：传
ThreadPoolExecutor(max_workers=3)，避免默认池挤占事件循环资源 - CPU 密集型：换
ProcessPoolExecutor，否则线程池反而加剧 GIL 竞争 - 绝对不要在
run_in_executor里传lambda或闭包引用大对象，容易内存泄漏
真正麻烦的从来不是“不知道该用哪个 sleep”，而是把 time.sleep() 当作通用延时工具，嵌在异步上下文里还浑然不觉。那些藏在工具函数、重试逻辑、日志封装里的调用，才是最常导致协程“饿死”的隐形源头。
