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 位置和逻辑流不一致。 Ideogram Ideogram是一个全新的文本转图像AI绘画生成平台，擅长于生成带有文本的图像，如LOGO上的字母、数字等。