Python文件锁在多进程下基本可靠但有前提：flock()是Unix/Linux/macOS内核级锁，崩溃自动释放；Windows的msvcrt.locking()为脆弱的advisory锁，易残留死锁；需统一路径、避免混用锁类型、合理控制粒度，或选用Redis等分布式锁替代。
Python 文件锁在多进程环境下基本可靠，但有重要限制和使用前提。它不是万能的同步机制，能否真正起作用，取决于锁的类型、操作系统支持、文件系统特性以及是否所有进程都遵循同一套加锁逻辑。
fcntl.flock 是最常用且跨进程有效的选择
（仅限 Unix/Linux/macOS）
基于 flock() 系统调用的文件锁是内核级的，由操作系统维护，进程崩溃或异常退出时会自动释放锁，对多进程协作较友好。
- 所有参与协作的进程必须对同一个打开的文件描述符（或通过同一路径打开的文件）调用
flock() - 不依赖文件内容或路径名本身，而是依赖底层 inode 和内核锁表，所以硬链接、符号链接不影响锁有效性
- 注意：不同进程用
open()单独打开同一路径，得到的是独立 fd，但flock()仍能协同工作——这是它适合多进程的关键
msvcrt.locking 在 Windows 上可用但局限明显
（仅限 Windows，且仅支持字节范围锁）
立即学习“Python免费学习笔记（深入）”；
Windows 下没有直接对应 flock() 的内核锁，msvcrt.locking() 提供的是基于文件句柄的 advisory 锁，行为更脆弱：
- 需要显式指定锁定的字节范围，通常得约定好锁区域（如文件开头 1 字节）
- 若进程未调用解锁就崩溃，锁可能残留，导致死锁（需靠超时或外部清理）
- 某些文件系统（如网络共享 SMB）可能不支持或弱支持该锁，可靠性下降
避免踩坑的关键实践
即使选对了锁机制，错误用法也会让锁失效：
-
不要混用锁类型：比如一个进程用
flock()，另一个用fcntl.lockf()或自定义文件标记，它们互不感知 - 锁文件必须可被所有进程访问：路径需统一（推荐绝对路径），权限要放开，不能放在临时目录或用户私有路径下
-
始终检查返回值并处理阻塞/超时：避免无限等待；用
LOCK_NB配合重试更健壮 - 锁粒度要合理：不要整个程序只用一个锁文件，应按资源隔离（如每个配置文件、每个数据库分片单独加锁）
替代方案更稳妥的场景
当文件锁难以满足需求时，可考虑：
- 使用 multiprocessing.Manager() 或 multiprocessing.Lock：适用于同父进程派生的子进程，不跨 Python 实例
-
借助外部服务：Redis 的
SET key value NX PX timeout、ZooKeeper、etcd 等提供分布式锁，适合异构进程或跨机器场景 -
信号量文件 + 原子操作：用
os.open(..., os.O_CREAT | os.O_EXCL)创建唯一临时文件作为锁标记，依赖文件系统原子性，轻量但需手动清理
