多进程写文件错乱的根本原因是write()系统调用在无同步机制下不保证原子性，尤其超PIPE_BUF时会被拆分；Linux/macOS用fcntl.fl

ock加文件描述符级建议锁，Windows需用msvcrt.locking实现字节范围锁。

Python 多进程写文件时为什么直接 open + write 会出错

多个进程同时 open('log.txt', 'a') 并调用 write()，看似安全，实际常出现内容错乱、覆盖、甚至部分写入丢失。根本原因不是 Python 层面的 GIL（多进程绕过 GIL），而是底层系统调用 write() 在没有同步机制时，对同一文件描述符的并发操作不保证原子性——尤其当写入量超过 PIPE_BUF（通常 4KB）时，write() 可能被拆成多次系统调用，中间插入其他进程的写入。

Linux/macOS 下用 fcntl.flock 实现进程级文件锁

flock() 是最常用、语义清晰的方案，它基于内核维护的 advisory lock（建议锁），要求所有参与者主动调用加锁/解锁，不强制拦截非法写入，但足够可靠。

• 锁是文件描述符粒度的，不是文件路径粒度：必须在 open() 后对返回的 fd 加锁，且子进程继承 fd 时锁状态可能变化（默认不继承，需设 FD_CLOEXEC=0 才可跨 fork 传递）
• 使用 flock(fd, fcntl.LOCK_EX) 加排他锁，写完后 flock(fd, fcntl.LOCK_UN) 解锁；推荐配合 try/finally 或上下文管理器
• 不要对已关闭的 fd 调用 flock()，会报 OSError: [Errno 9] Bad file descriptor
• 示例片段：

  import fcntl
  import os
  

fd = os.open('data.txt', os.O_RDWR | os.O_CREAT) try: fcntl.flock(fd, fcntl.LOCK_EX) os.lseek(fd, 0, os.SEEK_END) os.write(fd, b'new line\n') finally: fcntl.flock(fd, fcntl.LOCK_UN) os.close(fd)

Windows 下必须用 msvcrt.locking 替代 flock

Windows 不支持 flock()，且其 open() 返回的文件对象不提供原生锁接口。唯一可移植的底层方案是 msvcrt.locking()，但它只作用于已打开的文件对象的字节区域，且仅限于普通磁盘文件（不支持管道、设备等）。

• 必须用 os.open() 获取原始 fd，再用 os.fdopen(fd, 'r+b') 包装为文件对象，否则 msvcrt.locking() 会失败
• 锁定范围需明确指定字节偏移和长度，例如锁定整个文件可传 0 偏移 + 1 字节长度（因 Windows 的 lock 是“字节范围锁”，最小单位是 1 字节，且锁任意一字节即阻塞对该文件全部写入）
• 调用前确保文件已存在且可写，否则 locking() 抛 IOError: No locks available
• 示例关键步骤：

  import os
  import msvcrt
  

fd = os.open('log.txt', os.O_RDWR | os.O_CREAT) try:

锁定第 0 字节（效果等同锁整个文件）

msvcrt.locking(fd, msvcrt.LK_NBLCK, 1)  # 非阻塞，失败抛异常
os.lseek(fd, 0, os.SEEK_END)
os.write(fd, b'win log\n')

finally: msvcrt.locking(fd, msvcrt.LK_UNLCK, 1) os.close(fd)

跨平台封装要注意的三个坑

真正落地时，不能简单 if-else 切换锁模块，还要处理：

• fcntl 和 msvcrt 的异常类型不同：flock() 抛 OSError，locking() 抛 IOError（Py3 中已继承自 OSError，但仍需统一捕获）
• Windows 下 LOCK_NB 对应 msvcrt.LK_NBLCK，但 Linux 的 LOCK_NB 是 flag，需与 LOCK_EX 按位或；而 Windows 是独立常量
• 最容易被忽略的是：锁只对「通过该 fd 写入」起作用；如果某进程绕过锁、直接用 open(..., 'a').write()，锁完全无效——advisory lock 的本质就是靠自觉

文件锁不是银弹，它解决的是“多个进程协调写同一文件”的问题，而不是替代日志轮转、队列分发等更高层设计。真要高频写共享文件，优先考虑用 multiprocessing.Queue 或临时文件 + 原子重命名。