根本原因是StreamHandler底层write()非原子性导致日志交叉或丢失；官方推荐用QueueHandler+QueueListener分离记录与输出，确保线程安全且高性能。
为什么 logging 在多线程里会乱序或丢日志
根本原因不是 logging 本身不线程安全，而是默认的 StreamHandler（比如输出到 sys.stdout）底层调用的是系统级的 write()，而 Python 的 print() 和直接写 sys.stdout 在多线程下没有原子性——两段日志内容可能被交叉写入同一行，或者缓冲区未及时刷出导致丢失。
- 典型现象：
INFO:root:Start和INFO:root:Done拼成INFO:root:StartDone，或某条日志完全没出现 - 触发场景：多个线程高频调用
logger.info()，尤其配合basicConfig()简单配置时 - 关键点：
Logger对象是线程安全的，但它的Handler不一定；QueueHandler+QueueListener是官方推荐的解法，而非加锁或重写Handler
用 QueueHandler + QueueListener 彻底隔离 I/O
把日志记录动作和实际输出彻底拆开：所有线程只往队列发日志，单独一个线程负责从队列取、格式化、写文件/终端。这样避免了并发写同一资源的问题，也消除了锁竞争带来的性能拖累。
- 必须显式创建
Queue实例，不能复用queue.Queue()默认参数——建议设maxsize=1000防止内存无限增长 -
QueueHandler要替换掉原有StreamHandler或FileHandler，否则日志仍会走原路径 -
QueueListener必须调用.start()，且最好在主线程退出前调用.stop()，否则可能丢最后几条日志 - 示例关键片段：
import logging
from logging.handlers import QueueHandler, QueueListener
import queue
<p>log_queue = queue.Queue(maxsize=1000)
logger = logging.getLogger()
logger.setLevel(logging.INFO)</p><h1>替换掉默认 handler</h1><p>for h in logger.handlers[:]:
logger.removeHandler(h)
logger.addHandler(QueueHandler(log_queue))</p><h1>单独线程处理输出</h1><p>file_handler = logging.FileHandler("app.log")
console_handler = logging.StreamHandler()
listener = QueueListener(log_queue, file_handler, console_handler)
listener.start()</p><h1>后续所有线程调用 logger.info() 都安全别踩这些坑：常见配置错误
很多问题不是逻辑错，而是配置漏了一步，导致看似用了队列，实则日志还在原路跑。
- 忘记移除原有
Handler：调用basicConfig()后再加QueueHandler，结果日志同时走两路，乱序更严重 -
QueueListener没start()：队列一直积压，主线程结束时进程退出，队列里日志全丢 - 用
RotatingFileHandler时没设delay=True：首次写日志时自动创建文件，但多线程下可能多个线程同时尝试创建，报FileExistsError - 日志格式化器（
Formatter）只绑给QueueListener里的Handler，不要绑给QueueHandler——它不负责格式化
什么时候可以不用队列？简单场景的替代方案
如果只是偶尔打几条调试日志，或线程数极少（≤2）、日志频率极低（每秒 ≤1 条），直接用 threading.Lock 包一层也能凑合，但得清楚代价。
立即学习“Python免费学习笔记（深入）”；
- 锁住整个
logger.info()调用：吞吐量直接变成串行，线程越多越卡 - 只锁
handler.emit()：要继承StreamHandler重写，且依然无法解决RotatingFileHandler的文件轮转竞态 - 用
NullHandler+ 外部集中收集：适合调试阶段把日志发到本地 UDP 端口，由另一个进程接收，但增加部署复杂度 - 真正省事又可靠的方式，还是老实用
QueueHandler——它已被 Python 标准库验证多年，不是权宜之计
队列方案的麻烦点在于初始化稍重，容易漏掉 listener.start() 或忘记清理；但只要这一步做对，后续所有线程调用都无需额外处理，这才是它值得用的根本原因。
