async函数中禁用time.sleep()等同步阻塞调用，须改用await asyncio.sleep()；同步I/O（如requests、json.loads）需替换为异步版本或通过run_in_executor谨慎处理，否则会卡死事件循环。
async 函数里直接调用 time.sleep() 会卡死事件循环
协程不是线程，time.sleep() 是同步阻塞调用，它会让当前线程停住——而 asyncio 的事件循环就跑在这个线程上。一旦卡住，所有待调度的 await 任务都得干等。
常见错误现象：asyncio.run(main()) 启动后，程序看起来“假死”，其他协程完全不执行，CPU 占用低，日志停在某次 time.sleep(5) 上。
- 别用
time.sleep()，改用await asyncio.sleep(5) - 如果只是模拟延迟，
asyncio.sleep()是唯一正解；它会把控制权交还给事件循环，让别的协程继续跑 - 注意参数单位一致：两者都是秒，但
asyncio.sleep()支持 float（比如0.1），且不会因系统精度抖动
第三方同步库（如 requests、json.load）不能直接 await
像 requests.get()、open().read()、sqlite3.connect() 这些全是同步阻塞 I/O，它们内部会一直占着线程不放，导致事件循环无法切换任务。
使用场景：你想在异步 Web 服务（如 FastAPI、aiohttp）里调一个 HTTP 接口，或读一个大配置文件。
立即学习“Python免费学习笔记（深入）”；
- HTTP 请求优先换用
aiohttp或httpx.AsyncClient，它们是真正异步的 - 文件读写可用
await aiofiles.open(...).read()（需装aiofiles） - 数据库操作必须用异步驱动：比如
aiosqlite、asyncpg，而不是sqlite3或psycopg2 - 实在没异步版？只能用
loop.run_in_executor()把同步调用扔进线程池——但这是兜底方案，别当默认写法
run_in_executor 不是万能解药，用错反而更慢
把同步函数丢进线程池，确实能避免卡死事件循环，但线程创建、上下文切换、GIL 争抢全都在后台发生。高频调用时，开一堆线程比纯同步还慢。
性能影响：默认 ThreadPoolExecutor 最大线程数是 CPU 核心数 × 5，如果并发请求 100 个，每个都 run_in_executor 调一次 requests.get()，实际可能起 50+ 线程，内存和调度开销陡增。
- 只对「无法替代的同步黑盒」用，比如调用某个闭源 SDK 或遗留 C 扩展
- 显式传入复用的
ThreadPoolExecutor实例，避免反复创建销毁线程池 - 别在循环里反复
await loop.run_in_executor(None, sync_func, x)；先批量收集参数，再一次性提交 - 注意异常传播：线程里抛的异常会包装成
concurrent.futures.CancelledError或原样抛出，但堆栈可能不完整
async def 里混用同步逻辑，debug 时容易漏掉隐性阻塞点
最麻烦的不是明面上的 time.sleep()，而是那些看起来“无害”的同步操作：比如遍历超大列表做复杂计算、用正则反复 match、或者调用某个看似轻量实则内部做磁盘扫描的函数。
容易踩的坑：本地测试数据小，一切正常；一上生产，用户上传 10MB JSON，json.loads() 在主线程里解析 300ms，整个事件循环就卡了 300ms。
- 用
sys.settrace()或asyncio.debug=True启动时加-d参数，可捕获“长时间未让出控制权”的协程 - 对 CPU 密集型操作（如加密、图像处理），必须用
loop.run_in_executor(None, cpu_bound_func)，且考虑是否该移到专用进程（ProcessPoolExecutor） - 检查依赖库文档，确认其 async 版本是否存在；很多库（如
pydantic）v2 起已原生支持异步序列化
真正的难点不在“怎么写 async”，而在识别哪些调用表面安静、实则暗中锁死事件循环——尤其当它藏在三层封装之后。
