logging多线程乱序丢日志是因为handler.emit()不线程安全，导致i/o和格式化竞争；官方推荐用queuehandler+queuelistener方案，由单线程消费队列统一落盘。
为什么 logging 在多线程里会打印乱序甚至丢日志
因为 Python 的 logging 模块默认不是线程安全的——准确说，Handler 的 emit() 方法本身不加锁，多个线程同时调用时可能互相覆盖写入缓冲区、竞争文件指针，或触发 Formatter.format() 中的共享状态冲突。常见现象包括：两行日志内容挤在同一行、时间戳错位、某条日志完全没出现。
这不是配置问题，也不是日志级别设错了，而是底层 I/O 和格式化过程缺乏同步控制。
- 典型错误现象：
INFO:root:A和WARNING:root:B混成INFO:root:AWARNING:root:B - 使用场景：Web 后端（如 Flask 多线程模式）、爬虫并发任务、后台定时任务池
- 注意：
Logger实例本身是线程安全的（它内部用了锁），但真正出问题的是下游Handler的输出环节
用 QueueHandler + QueueListener 解决主线程落盘
这是官方推荐方案：把日志事件全塞进一个线程安全的 queue.Queue，再由单独一个消费者线程统一交给 Handler 写入。既避免了多线程争抢 I/O，又不阻塞业务逻辑。
关键点在于，所有工作线程只往队列发消息，真正的磁盘/网络操作由 QueueListener 串行完成。
立即学习“Python免费学习笔记（深入）”；
- 必须显式启动
QueueListener：listener.start()，否则日志永远卡在队列里 -
QueueHandler不要直接 add 到 root logger，应 add 到你自己的Logger实例，避免污染全局 - 如果程序提前退出，记得调用
listener.stop()并queue.join()，否则可能丢最后几条日志 - 性能影响小：
queue.put_nowait()是 O(1)，比每次打开文件快得多
import logging
from logging.handlers import QueueHandler, QueueListener
import queue
<p>log_queue = queue.Queue(-1)
handler = logging.FileHandler("app.log")
listener = QueueListener(log_queue, handler)
listener.start() # ⚠️ 忘记这句就等于没配</p><p>logger = logging.getLogger("myapp")
logger.addHandler(QueueHandler(log_queue))
logger.setLevel(logging.DEBUG)</p>别碰 threading.Lock 手动包 FileHandler
有人试图给 FileHandler.emit() 加锁，或者在外层用 with lock: 包住 logger.info() —— 这样做不仅无效，还可能引发死锁。
原因很简单：FileHandler 内部有缓冲、刷新、编码等多步操作，手动加锁只覆盖其中一段；更麻烦的是，日志库自身在某些路径（比如异常回溯格式化）也会递归调用 emit()，锁可能被重入或阻塞主线程。
- 错误示例：
with my_lock: logger.info("xxx")—— 锁的是调用动作，不是日志落地行为 - 兼容性风险：Python 3.12+ 对
logging内部锁机制做了调整，自定义锁容易和内置逻辑冲突 - 真正需要同步的不是“打日志”这个动作，而是“写磁盘”这个动作；前者该快，后者该稳
异步框架（如 asyncio）下不能直接复用 QueueListener
QueueListener 基于普通线程，它内部的 queue.get() 是阻塞调用，在 asyncio 主循环里会卡死整个 event loop。
如果你用的是 FastAPI、Tornado 异步模式，或自己写了 async def 日志函数，得换思路：要么用支持异步的第三方库（如 aiologger），要么把日志推到进程级队列（如 multiprocessing.Queue）再由独立进程处理。
- 不要尝试在
async函数里await loop.run_in_executor(None, logger.info, ...)—— 开销大且仍可能错乱 -
aiologger的AsyncFileHandler底层用loop.run_in_executor封装了线程安全写入，比手写更可靠 - 注意：即使用了异步日志库，也要检查其是否对
Formatter做了线程/协程隔离，有些库只解决了 I/O，没解决格式化阶段的共享状态
事情说清了就结束。最常被忽略的其实是 QueueListener.start() 和 listener.stop() 的配对，以及异步场景下误把线程模型套过去。
