直接追加写会丢数据，因‘a’模式下“定位+写入”非原子操作，多进程可能同时定位到同一偏移导致覆盖或交错；需用portalocker锁住整个写入过程并确保落盘。
为什么直接追加写会出问题
多个进程同时用 open(..., 'a') 打开同一文件并写入，看似安全，实际可能丢数据。因为 'a' 模式只保证“写入位置移到末尾”，但“定位 + 写入”不是原子操作。两个进程几乎同时执行时，可能都定位到同一个偏移，后写的覆盖前写的，或内容交错成乱码。
常见现象包括：日志行缺失、JSON 日志变成非法格式、CSV 行错位。这不是 Python 的 bug，是操作系统层面的竞态。
portalocker.lock() 要锁整个文件，不是锁写入动作portalocker 的本质是调用底层 flock()（Linux/macOS）或 LockFileEx()（Windows），锁的是文件描述符对应的 inode，不是某段逻辑。所以必须：
- 在写入前获取锁（
portalocker.lock() 或上下文管理器）
- 锁住期间完成全部写入（含
flush() 和 os.fsync()）
- 写完立即释放锁（推荐用
with 语句）
portalocker.lock() 或上下文管理器）flush() 和 os.fsync()）with 语句）不能只锁 write() 那一行——锁必须覆盖从定位到落盘的全过程。
import portalocker
with open('log.txt', 'a') as f:
portalocker.lock(f, portalocker.LOCK_EX)
f.write('hello\n')
f.flush()
os.fsync(f.fileno()) # 确保真正写入磁盘
避免死锁和阻塞：超时与非阻塞模式
默认 portalocker.lock() 会无限等待，一旦某个进程崩溃没释放锁，其他进程就卡死。生产环境必须设超时：
- 用
timeout=2 参数控制最大等待秒数
- 或改用
LOCK_NB（non-blocking），失败立刻抛 portalocker.LockException
timeout=2 参数控制最大等待秒数LOCK_NB（non-blocking），失败立刻抛 portalocker.LockException
常见错误是忽略异常处理，导致程序静默失败或 crash：
情感家园企业站5.0 多语言多风格版
下载
一套面向小企业用户的企业网站程序！功能简单，操作简单。实现了小企业网站的很多实用的功能，如文章新闻模块、图片展示、产品列表以及小型的下载功能，还同时增加了邮件订阅等相应模块。公告，友情链接等这些通用功能本程序也同样都集成了！同时本程序引入了模块功能，只要在系统默认模板上创建模块，可以在任何一个语言环境（或任意风格）的适当位置进行使用！
-
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 自动释放）
os.open() + os.fdopen() 控制 flagsclose_fds=True 传给 subprocess.Popen）portalocker.unlock() 清理残留锁（仅调试用，正常流程靠 with 自动释放）最易被忽略的一点：锁只对调用 portalocker.lock() 的进程有效，如果另一个进程用 C 写的工具或 shell >> 直接追加，它完全不感知 Python 的锁——portalocker 不是全局文件写保护机制，只是协作式互斥。
