如何在Python中开启asyncio的Debug模式排查事件循环卡顿？-Python教程-PHP中文网

asyncio.run(main(), debug=True)是最直接启用debug模式的方式，它自动开启事件循环调试、暴露未await协程、未关闭任务等异常，并输出slow callback等关键警告。

如何在python中开启asyncio的debug模式排查事件循环卡顿？

Python 3.7+ 的 asyncio.run() 支持直接传入 debug=True，这是开启 asyncio 调试模式最简单、最推荐的方式。它会自动启用事件循环的调试开关，并在出现慢回调、未完成任务、未处理异常等场景时输出警告或错误信息。

仅需改一行：把 asyncio.run(main()) 换成 asyncio.run(main(), debug=True)
无需手动获取或配置事件循环，避免因多次调用 asyncio.get_event_loop() 导致的 RuntimeError: no running event loop
底层等效于设置 loop.set_debug(True) + 启用 asyncio.get_event_loop().slow_callback_duration = 0.1（默认阈值 0.1 秒）

如果你绕过 asyncio.run()、自己创建并运行事件循环（比如用 loop.run_until_complete()），就必须显式调用 set_debug(True)，且必须在事件循环启动前设置——否则无效。

错误写法：loop = asyncio.new_event_loop() → loop.run_until_complete(main()) → loop.set_debug(True)（太晚，不起作用）
正确顺序：loop = asyncio.new_event_loop() → loop.set_debug(True) → loop.run_until_complete(main())
在协程内部不能用 asyncio.get_event_loop() 获取正在运行的 loop 来设 debug；应使用 asyncio.get_running_loop()，但注意它只在协程中可用，且设 debug 对当前 loop 有效，但无法改变已启动的 slow callback 检测阈值

开启 debug 后，真正能暴露卡顿问题的日志通常有两种：

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

Executing <...> took s, which exceeds the configured threshold of s —— 表明某个回调（比如 loop.call_soon() 注册的函数、asyncio.sleep(0) 后的调度点）执行超时，N 远大于 T（默认 0.1）说明有同步阻塞操作混入
Task was destroyed but it is pending! 或 Unclosed client session —— 不一定直接导致卡顿，但反映资源未清理、任务被粗暴取消，可能掩盖真实瓶颈
注意：这些日志默认输出到 stderr，若你重定向了日志，需确保 warnings 和 asyncio 日志级别没被过滤（如 logging.basicConfig(level=logging.DEBUG) 可见）

debug 模式只报现象，不自动定位根源。看到 slow callback 后，要立刻检查以下几类代码：

同步 I/O：比如在协程里直接调用 requests.get()、open()、time.sleep() —— 必须换成 aiohttp.ClientSession、aiopath 或 asyncio.sleep()
CPU 密集型操作：如大数组计算、JSON 解析、正则匹配 —— 应用 loop.run_in_executor() 托管到线程池
第三方库未适配 async：某些 ORM（如早期 SQLAlchemy）或 SDK 默认是同步的，需确认是否提供 async 版本或配套驱动（如 asyncpg 而非 psycopg2）
死锁式 await：比如两个协程互相 await 对方的 asyncio.Event 或 asyncio.Lock，debug 不会直接提示，但会导致事件循环长时间无进展，此时需结合 asyncio.all_tasks() 查看哪些 task 卡在 WAITING 状态