多进程写文件错乱的根本原因是write()系统调用在无同步机制下不保证原子性，尤其超PIPE_BUF时会被拆分；Linux/macOS用fcntl.flock加文件描述符级建议锁，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 </li></ul><p>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)</p>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 </li></ul><p>fd = os.open('log.txt', os.O_RDWR | os.O_CREAT) try:</p><h1>锁定第 0 字节（效果等同锁整个文件）</h1><pre class='brush:python;toolbar:false;'>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或临时文件 + 原子重命名。 -
- 必须用
