多进程下logging日志乱序或丢失是因为filehandler非进程安全，多个进程同时写文件导致覆盖或截断；推荐用queuehandler+queuelistener由主进程统一落盘，或使用concurrent_log_handler加文件锁。
多进程下 logging 为什么日志会乱序或丢失
因为默认的 FileHandler 不是进程安全的——多个子进程同时写同一个文件，底层 write() 调用可能被内核打断，导致内容覆盖、截断或错行。不是“没打印”，而是写坏了。
- 典型现象：
RotatingFileHandler切割后部分日志消失；同一时间戳出现两条不连贯的日志；日志里突然夹着半句话 - 根本原因：Python 的
logging模块本身不处理跨进程同步，FileHandler底层调用的是 C 标准库的fwrite或系统write，无锁 - 别指望加
threading.Lock解决——它只管线程，不管进程
用 QueueHandler + QueueListener 是最稳的方案
让所有子进程把日志发到一个 multiprocessing.Queue，由主进程里的监听器统一落盘。这是官方推荐路径，也绕开了文件锁难题。
- 子进程只需配置
QueueHandler，把日志塞进队列，不碰文件 - 主进程起一个
QueueListener，绑定真实的FileHandler或RotatingFileHandler，负责消费和写入 - 注意：队列对象不能直接传给子进程，要用
multiprocessing.Manager().Queue()或在Process启动前创建好再传入 - 示例关键片段：
queue = multiprocessing.Queue()<br>handler = logging.FileHandler("app.log")<br>listener = logging.handlers.QueueListener(queue, handler)<br>listener.start()<br># 子进程中：<br>logger.addHandler(logging.handlers.QueueHandler(queue))
concurrent_log_handler 可以省事，但得知道它怎么锁
这个第三方包用文件级 flock 实现进程互斥，比自己手写队列轻量，适合快速落地，但有隐藏约束。
- 只支持 Unix/Linux/macOS（Windows 用
msvcrt.locking，行为略有差异） - 每次写日志都触发一次系统调用锁文件，高并发时可能成瓶颈，压测 QPS > 5k 时建议实测延迟
- 必须确保所有进程用完全相同的日志路径，否则锁失效——比如用相对路径
"logs/app.log"，而各进程工作目录不同，就等于在写不同文件 - 安装后替换原
FileHandler即可：from concurrent_log_handler import ConcurrentRotatingFileHandler<br>handler = ConcurrentRotatingFileHandler("app.log", "a", 512*1024, 5)
别在子进程中调用 logging.basicConfig()
它会偷偷新建 StreamHandler 并绑定到根 logger，不仅污染主进程配置，还可能和主进程的 QueueListener 冲突，导致日志重复或静默丢弃。
立即学习“Python免费学习笔记（深入）”；
- 子进程应该只获取已有 logger：
logging.getLogger("myapp")，不新建 handler - 主进程完成全部 handler 设置（包括
QueueHandler绑定）后再启动子进程 - 如果用了
spawn启动方式（macOS/Linux 默认），子进程不会继承主进程的 logger 配置，这点比fork更容易出问题 - 调试时加一句
print(logger.handlers)看子进程里到底挂了啥 handler，比猜快得多
实际部署时最容易忽略的是子进程的 logger 名称一致性——名称不同就拿不到主进程配好的 QueueHandler，日志直接走默认的 NullHandler，悄无声息地消失。
