根本原因是python默认filehandler和streamhandler非进程安全，多进程并发写同一文件或stdout会导致乱序、丢日志；应使用queuehandler+queuelistener方案实现跨进程安全日志。
多进程里 logging 一用就乱序、丢日志，根本原因是什么
不是日志写错了，是 Python 默认的 FileHandler 和 StreamHandler 不是进程安全的。多个子进程同时往同一个文件或 stdout 写日志时，会抢锁失败、缓冲区错位、甚至覆盖彼此内容——尤其在高并发写小日志时，OSError: [Errno 9] Bad file descriptor 或空行、截断都算轻的。
关键点在于：每个子进程都得有自己独立的日志资源，或者用跨进程安全的同步机制。
- 别复用主进程创建的
logger实例，子进程里要重新配置 - 避免所有进程共用一个
FileHandler对象（哪怕路径相同也不行） -
RotatingFileHandler在多进程下默认不安全，除非配合delay=True+ 外部同步
用 QueueHandler + QueueListener 是最稳的方案
这是官方推荐的跨进程日志转发模式：每个子进程只往一个 multiprocessing.Queue 发日志；主进程开一个监听线程，统一消费并写入文件。全程无文件竞争，顺序可控，也支持 RotatingFileHandler 等高级功能。
实操要点：
立即学习“Python免费学习笔记（深入）”；
- 子进程中必须调用
logging.setLoggerClass(logging.Logger)重置 logger 类（否则 multiprocessing fork 后可能残留旧状态） - 子进程里只加
QueueHandler，别加任何其他 handler - 主进程启动
QueueListener前，确保日志目录已存在，否则FileHandler初始化失败会静默吞掉异常 - 别忘了在主进程退出前调用
queue_listener.stop()，否则子进程可能卡在队列写入上
示例片段（主进程）：
queue = multiprocessing.Queue(-1) queue_handler = logging.handlers.QueueHandler(queue) logger.addHandler(queue_handler) queue_listener = logging.handlers.QueueListener(queue, file_handler) queue_listener.start()
multiprocessing.get_logger() 能不能直接用
能，但只适合调试，别用于生产。它底层用的是 StreamHandler 输出到 stderr，没做任何同步，且返回的 logger 是全局单例——多个子进程写同一 stderr 流，必然乱序。更麻烦的是，它的 level 默认是 WARNING，你调了 setLevel(logging.DEBUG) 也可能被父进程覆盖。
- 它不支持自定义格式、文件输出、轮转等基本需求
- 在 Windows 上表现更差（spawn 方式下 logger 实例可能为空）
- 如果用了
concurrent.futures.ProcessPoolExecutor，它压根不触发get_logger()的初始化逻辑
想省事用文件名区分进程？注意命名和清理
给每个子进程配独立日志文件（比如加 os.getpid()）确实简单，但容易埋坑：
- 文件名别只用
pid，加个时间戳或任务 ID，否则重启后 pid 复用导致日志覆盖 - 大量子进程会产生一堆零散日志文件，得自己实现归档逻辑，
TimedRotatingFileHandler在这种场景下完全失效 - Windows 下文件句柄限制更紧，开太多
FileHandler可能触发OSError: [Errno 24] Too many open files - 别在子进程退出时自动删日志文件——万一主进程要合并分析，就找不到了
这法子适合短期脚本或 debug，长期运行的服务必须上 QueueHandler。
真正难的不是选哪种方式，是子进程里 logger 的初始化时机和上下文隔离——fork 后不重置 handler、不清理旧 handler 引用，再好的方案也会漏日志。
