multiprocessing中直接用logging会丢日志或乱序，因子进程继承父进程logger但FileHandler非进程安全，多进程写同一文件导致缓冲冲突、覆盖或OSError；应让各子进程独立配置logger或使用QueueHandler+QueueListener。
为什么 multiprocessing 中直接用 logging 会丢日志或乱序？
因为每个子进程会继承父进程的 logger 对象，但底层 handler（比如 FileHandler）不是进程安全的——多个进程同时写同一个文件，会导致缓冲区冲突、覆盖、截断，甚至 OSError：[Errno 9] Bad file descriptor。标准库的 logging 模块本身不保证跨进程写入安全。
推荐方案：每个子进程独立初始化 logger
避免共享 handler，让每个进程持有一个专属的 FileHandler 或转向进程安全的中转方式。最简单可靠的做法是：在子进程入口函数里调用 logging.basicConfig() 或手动配置 logger，确保 handler 不被复用。
- 不要在主进程配置好 logger 后直接传给子进程（
Process(target=..., args=(logger,))） - 子进程中禁用继承：调用
logging.getLogger().handlers.clear()再重新 addHandler - 若需统一日志文件，改用
QueueHandler + QueueListener（见下一条） - 注意
basicConfig()在子进程中首次调用才生效；重复调用无效
需要合并到单个文件？用 QueueHandler + QueueListener
这是官方推荐的跨进程日志方案：所有子进程把 log record 发到一个 multiprocessing.Queue，由主进程里的 QueueListener 统一消费并写入文件。它规避了并发写问题，也保留了时间戳和进程名等上下文。
- 必须在主进程创建
Queue和QueueListener，并在主进程启动 listener（.start()） - 子进程拿到
Queue实例后，用QueueHandler(queue)替换默认 handler - 主进程退出前要调用
listener.stop()，否则可能丢失最后几条日志 - 注意
Queue是阻塞的，如果 listener 崩溃或没运行，子进程会卡住
import logging from logging.handlers import QueueHandler, QueueListener from multiprocessing import Process, Queuedef worker(q): logger = logging.getLogger() logger.setLevel(logging.INFO) logger.addHandler(QueueHandler(q)) # 只发不写 logger.info("from worker %d", Process.pid)
if name == "main": q = Queue() handler = logging.FileHandler("app.log") listener = QueueListener(q, handler) listener.start()
p = Process(target=worker, args=(q,)) p.start() p.join() listener.stop() # 关键：必须显式 stop调试时别忽略
spawnvsfork的影响Windows 默认用
spawn启动子进程（重新导入主模块），而 Linux/macOS 默认fork（内存拷贝）。这直接影响日志配置时机：立即学习“Python免费学习笔记（深入）”；
-
spawn下，子进程不会执行 if __name__ == "__main__": 块外的代码，所以 logger 初始化必须放在 worker 函数内 -
fork下，子进程可能意外继承父进程已打开的FileHandler文件句柄，导致OSError: [Errno 9] - 统一做法：在 worker 开头加
logging.getLogger().handlers.clear()，再重建 handler
真正麻烦的是混合场景——比如用 concurrent.futures.ProcessPoolExecutor，底层可能切换启动方法，日志行为会悄悄变化。
