portalocker.lock() 锁不住多进程写入的根本原因是LOCK_EX锁依赖同一文件对象，而各进程独立open导致锁隔离；正确做法是统一用portalocker.Lock上下文管理器配合'a'模式、flush及本地文件系统。
portalocker.lock() 为什么锁不住多进程写入？
根本原因不是 portalocker 不行，而是默认用的 LOCK_EX（独占锁）在某些文件系统或 Python 进程模型下不跨进程生效——尤其当多个进程打开的是同一路径但不同文件对象时，锁是各自独立的。Windows 上表现更“可靠”，Linux/macOS 下常见失效。
- 必须确保所有进程都对**同一个已打开的文件对象**调用
lock()，而不是各自open('data.txt')后再锁 - 推荐统一用
portalocker.Lock上下文管理器，它会自动处理文件打开+锁+释放 - 避免在子进程中重复 open + lock：父进程打开后传 fd 给子进程（不推荐），或让每个进程都走完整的
Lock流程（推荐）
用 portalocker.Lock 正确加锁的最小可行写法
别手写 f = open(); portalocker.lock(f, ...)，容易漏 unlock 或异常没释放。直接用上下文管理器最稳：
import portalocker
<p>with portalocker.Lock('shared.log', 'a') as f:
f.write('process-123: done\n')
f.flush() # 关键：避免缓冲区导致写入延迟，锁释放后内容还没落盘</p>-
'a'模式比'w'更安全：不截断原文件，多个进程追加写不会互相覆盖 - 必须加
f.flush()：否则即使锁已释放，内容可能还在用户态缓冲区，别的进程读不到最新数据 - 不要用
encoding='utf-8'直接传给Lock()—— 它只接受二进制模式参数，文本需自己 decode/encode
Linux 下 portalocker 失效的典型错误现象和绕过方式
现象：portalocker.Lock 不报错，但两个进程同时写入同一文件，内容错乱或丢失。这不是 bug，是底层 flock() 在 NFS 或某些容器环境里不保证跨主机/跨 mount 点一致性。
- 先确认是否真在用本地 ext4/xfs：运行
df -T .，如果不是ext4/xfs，flock行为不可靠 - 临时验证：改用
fcntl.flock()手动锁，效果一致 → 说明是系统级限制，不是 Python 层问题 - 硬需求场景可换方案：用 Redis 的
SET key value NX EX 30做分布式锁，或写一个轻量级基于文件原子重命名的信号文件（os.replace()）
锁文件 vs 锁内容：portalocker 不解决数据结构并发问题
portalocker 只管“这个文件此刻能不能写”，不管“写进去的数据逻辑上是否自洽”。比如多个进程都读取 JSON 文件 → 修改某个字段 → 写回，锁住文件也救不了竞态。
立即学习“Python免费学习笔记（深入）”；
- 它防的是字节流层面的覆盖，不是业务逻辑层面的冲突
- 如果要修改结构化数据（JSON/YAML/CSV），必须把“读-改-写”整个流程包在同一个
Lock里，且确保中间不 sleep、不 await、不被信号中断 - 高频小更新（如计数器）建议改用数据库或 Redis，文件锁在这里是反模式
实际用的时候，最容易忽略的是 flush 和文件系统语义。锁住了不代表数据立刻可见，而可见性依赖底层存储行为——这点在容器、NAS、CI 环境里特别容易翻车。
