多进程追加写文件时如何使用文件锁（portalocker 示例）

直接追加写会丢数据，因‘a’模式下“定位 + 写入”非原子操作，多进程可能同时定位到同一偏移导致覆盖或交错；需用 portalocker 锁住整个写入过程并确保落盘。

为什么直接追加写会出问题 多个进程同时用 open(……, 'a') 打开同一文件并写入，看似安全，实际可能丢数据。因为 'a' 模式只保证“写入位置移到末尾”，但“定位 + 写入”不是原子操作。两个进程几乎同时执行时，可能都定位到同一个偏移，后写的覆盖前写的，或内容交错成乱码。

常见现象包括：日志行缺失、JSON 日志变成非法格式、CSV 行错位。这不是 Python 的 bug，是 操作系统 层面的竞态。

portalocker.lock() 要锁整个文件，不是锁写入动作portalocker 的本质是调用底层 flock()（Linux/macOS）或 LockFileEx()（Windows），锁的是文件描述符对应的 inode，不是某段逻辑。所以必须：

• 在写入前获取锁（portalocker.lock() 或上下文管理器）
• 锁住期间完成全部写入（含 flush() 和 os.fsync()）
• 写完立即释放锁（推荐用 with 语句）

不能只锁 write() 那一行——锁必须覆盖从定位到落盘的全过程。

import portalocker with open('log.txt', 'a') as f:     portalocker.lock(f, portalocker.LOCK_EX)     f.write('hellon')     f.flush()     os.fsync(f.fileno())  # 确保真正写入磁盘

避免死锁和阻塞：超时与非阻塞模式 默认 portalocker.lock() 会无限等待，一旦某个进程崩溃没释放锁，其他进程就卡死。生产环境必须设超时：

• 用 timeout=2 参数控制最大等待秒数
• 或改用 LOCK_NB（non-blocking），失败立刻抛 portalocker.LockException

常见错误是忽略异常处理，导致程序静默失败或 crash：

• try/except portalocker.LockException: 做降级（如打本地 debug 日志、发告警）
• 不要用 time.sleep() 循环重试——高并发下容易雪崩
• 多进程场景中，锁失败大概率说明有异常进程残留，应优先查它

Windows 下注意文件打开模式和句柄继承 Windows 对文件锁更严格：open(……, 'a') 默认带 O_APPEND，但某些 Python 版本（尤其旧版）在多进程 fork 后可能继承句柄导致锁失效。稳妥做法：

• 显式用 os.open() + os.fdopen() 控制 flags
• 确保子进程不继承父进程的文件句柄（close_fds=True 传给 subprocess.Popen）
• 测试时用 portalocker.unlock() 清理残留锁（仅调试用，正常流程靠 with 自动释放）

最易被忽略的一点：锁只对调用 portalocker.lock() 的进程有效，如果另一个进程用 C 写的 工具 或 shell >> 直接追加，它完全不感知 Python 的锁——portalocker 不是全局文件写保护机制，只是协作式互斥。