直接在async def中用logging.info会卡住，因为标准Handler（如FileHandler）是同步阻塞IO，会阻塞event loop；应改用QueueHandler+QueueListener方案，将日志写入内存队列，由独立线程落盘。
为什么直接在async def里用logging.info会卡住
因为标准logging的Handler（比如FileHandler或StreamHandler）默认是同步阻塞的——写日志时会直接调用write()或flush()，而这些IO操作在异步上下文中会阻塞整个event loop。哪怕只是logging.info("hello")，如果底层Handler碰上磁盘慢、终端缓冲满、或者被重定向到某个慢管道，就可能让协程停住几百毫秒甚至更久。
常见现象：你发现asyncio.sleep(0.1)实际耗时 200ms+，或并发请求的响应时间突然抖动，排查后发现是某处日志调用拖慢了。
- 别在
async def里直接调用logger.info()，除非你确认Handler完全无IO（比如NullHandler） - 不要试图用
loop.run_in_executor包装单条日志——开销大、易堆积、难控制 -
QueueHandler+QueueListener是官方推荐的解耦方案，它把日志“发出去”变成内存队列写入，真正落盘交给独立线程
怎么用QueueHandler把日志送出协程线程
QueueHandler本身不干活，只负责把LogRecord对象塞进一个queue.Queue；真正的IO由另一个线程里的QueueListener完成。关键点在于：队列写入是纯内存操作，极快且不会触发任何await点。
实操步骤：
立即学习“Python免费学习笔记（深入）”；
- 创建一个
queue.Queue实例（注意不是asyncio.Queue，后者不能跨线程） - 新建
QueueHandler并绑定该队列，把它加到你的logger的handlers中 - 用
QueueListener监听这个队列，并传入真正的IO Handler（如FileHandler） - 调用
listener.start()启动监听线程——必须在event loop启动前或主线程中调用
示例片段：
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
import logging
import queue
from logging.handlers import QueueHandler, QueueListener
<p>log_queue = queue.Queue()
handler = logging.FileHandler("app.log")
queue_handler = QueueHandler(log_queue)
logger = logging.getLogger("myapp")
logger.addHandler(queue_handler)
logger.setLevel(logging.INFO)</p><p>listener = QueueListener(log_queue, handler)
listener.start() # 这行必须在 asyncio.run() 之前执行</p>async def里怎么安全打日志
只要QueueHandler已生效，你在任意async def里调用logger.info()都是安全的——它内部只是log_queue.put_nowait(record)，没有await、没有IO、不抛异常（除非队列满且没设block=False）。
但要注意几个边界：
- 如果队列满了，默认会阻塞主线程（不是协程线程！），所以建议初始化时设
queue.Queue(maxsize=1000)，并搭配listener.enqueue_sentinel()做优雅退出 - 日志中的
exc_info、stack_info仍可正常捕获，因为LogRecord序列化发生在调用方线程（即协程所在线程），不是在监听线程 - 避免在日志格式化字符串里调用耗时函数（比如
f"result={slow_func()}"），这会在协程线程里执行，和Handler无关但照样拖慢协程
为什么不用asyncio.Queue + create_task监听
有人想用asyncio.Queue配合create_task在event loop里消费日志，听起来很“async native”，但实际问题很多：
-
asyncio.Queue不能被非async线程（比如QueueListener启的线程）安全put，会引发RuntimeError: There is no current event loop in thread - 如果你硬要在协程里用
await queue.get()，就得保证这个consumer task永不退出、且能处理背压——而标准logging模块不提供这种生命周期管理接口 -
QueueListener内置重试、sentinel信号、异常隔离，比手写consumer健壮得多；它的线程与event loop完全解耦，不会因日志IO拖慢任何协程调度
简单说：想省事又可靠，就老实用queue.Queue + QueueListener。非要“全async”方案，得自己实现一套日志协议，代价远超收益。
最容易被忽略的是listener.start()的调用时机——它必须在任何协程启动前完成，否则队列可能被协程先写入，而监听线程还没起来，导致日志丢失或卡死。这点连很多Stack Overflow答案都没强调清楚。
