asyncio.run() 开启 debug 模式只需传入 debug=True，可暴露协程未 await、任务未关闭等调度异常；自建事件循环需手动调用 loop.set_debug(True)，环境变量 PYTHONASYNCIODEBUG=1 亦可全局启用。
asyncio.run() 怎么开启 debug 模式
直接传 debug=True 就行，这是最简单也最容易被忽略的入口。不加这个，asyncio 会默默吞掉很多可疑调度行为，比如协程没被 await、事件循环关闭时还有待处理任务等。
常见错误现象：RuntimeWarning: coroutine 'xxx' was never awaited 在非 debug 模式下可能完全不报；或者程序莫名卡住几秒才退出，debug 模式下会立刻抛出 ResourceWarning: unclosed task。
-
asyncio.run(main(), debug=True)—— 推荐所有开发阶段都这么写 - 如果用自建事件循环（比如
loop = asyncio.new_event_loop()），得手动调loop.set_debug(True) - 环境变量
PYTHONASYNCIODEBUG=1也能全局生效，但不如代码里显式控制来得可靠
debug 模式下哪些日志真正有用
它不会打印“耗时多少”，而是暴露调度层面的异常信号：比如协程创建后长期没人 await、任务被取消但没清理、回调堆积、IO 多路复用器响应延迟等。重点盯三类输出：
- 以
Executing <task...> 开头的日志 —— 表示任务终于开始跑了，如果某任务迟迟不出这条，说明被卡在了 await 链某处</task...> -
Close callback <...> took ... seconds</...>—— 回调执行超时，常见于同步阻塞操作混入异步流程（比如在协程里调了time.sleep()或未用loop.run_in_executor包装的 CPU 密集函数） -
Scheduled callback <...> after ... seconds</...>—— 如果延迟值很大（比如 >0.1s），说明事件循环被长时间独占，大概率有同步代码或死循环
为什么 print() 和 logging 在 async 场景下容易误导人
因为 print() 是同步 IO，在高并发协程中可能被缓冲、重排，甚至出现在错误的时间点。更糟的是，某些 IDE 的调试器（如 PyCharm 默认配置）会在 await 处暂停，但实际执行顺序已由事件循环决定，print 位置和逻辑流不一致。
立即学习“Python免费学习笔记（深入）”；
- 别依赖
print("before await")+print("after await")判断耗时 —— 它们之间可能穿插了其他协程的执行 - 想测真实耗时，必须用
asyncio.get_event_loop().time()，不是time.time() - logging 需设
propagate=False并指定 handler，否则多协程写同一个文件句柄会乱序或阻塞
性能瓶颈不在 await，而在 await 的对象上
debug 模式本身不帮你定位慢在哪，但它能揪出“假异步”：比如你以为 await aiohttp.ClientSession().get(...) 是异步的，但如果 session 复用不当、DNS 解析阻塞、或服务端响应慢，它就只是个挂起的等待，不产生并发收益。
- 检查是否重复创建
aiohttp.ClientSession—— 每次新建 session 都要重建连接池和 cookie jar - 确认第三方库真支持异步：像
aiomysql可以，但直接用mysql-connector-python的普通接口就会阻塞整个 loop - 用
asyncio.wait_for(task, timeout=...)主动设超时，比等 debug 日志里出现close callback took...更早发现问题
debug 模式不会告诉你某次 HTTP 请求花了 2 秒，但它会告诉你这 2 秒里事件循环是不是空转了 —— 这才是异步调试最该盯住的分界点。
