flock不能替代fcntl做跨进程文件锁，因为flock是建议性锁且依赖文件描述符继承，在fork后行为不稳定，子进程关闭fd或exec时锁可能意外释放；而fcntl的F_SETLK是内核级强制锁，只要进程存活且fd未关闭，锁即持续有效，更适合严格同步场景。
为什么flock不能替代fcntl做跨进程文件锁？
因为flock是建议性锁且依赖文件描述符继承，在多进程fork后行为不稳定，尤其在子进程关闭fd或exec新程序时锁可能意外释放；而fcntl的F_SETLK是内核级强制锁，只要持有锁的进程存活、fd未关闭，锁就持续有效，更适合严格同步场景。
常见错误现象：OSError: [Errno 11] Resource temporarily unavailable——说明另一个进程已持写锁；IOError: [Errno 9] Bad file descriptor——fd在子进程中被提前关闭，导致锁失效。
- 必须用
os.open()打开文件（而非open()），才能获得可被fcntl.fcntl()操作的原始fd - 锁作用于整个文件，不支持字节范围锁以外的粒度（如某段偏移）
- Python 3.8+ 中
fcntl在Windows不可用，仅限Unix/Linux/macOS
如何用fcntl.flock和fcntl.fcntl区分使用？
fcntl.flock是flock(2)系统调用的封装，和fcntl模块里真正的fcntl.fcntl(fd, fcntl.F_SETLK, ...)不是一回事——前者仍是建议锁，后者才是POSIX强制锁。很多人误以为调用fcntl.flock就等于用了fcntl机制，其实它底层走的是flock系统调用。
正确做法：只用fcntl.fcntl()配合fcntl.F_SETLK/fcntl.F_SETLKW，传入struct.pack('hhll', ...)构造的锁结构体。
立即学习“Python免费学习笔记（深入）”；
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
-
F_SETLK：非阻塞，冲突时立即报错 -
F_SETLKW：阻塞等待，直到锁可用或被信号中断 - 锁结构体字段顺序固定：
type（fcntl.F_WRLCK或fcntl.F_RDLCK）、whence（通常0）、start（0）、length（0表示全文件）、pid（内核自动填，传0即可）
实际加锁代码中容易漏掉的关键步骤
最常被忽略的是：锁必须绑定在**未关闭的文件描述符**上，且该fd不能被子进程继承后意外关闭——否则锁立刻释放。这意味着不能依赖with open(...) as f:上下文管理器，也不能在fork()后让子进程执行os.close()或sys.stdout.close()等全局fd操作。
import fcntl
import os
import struct
<p>fd = os.open('/tmp/shared.lock', os.O_RDWR | os.O_CREAT)</p><h1>构造锁结构：type, whence, start, length, pid</h1><p>lock_data = struct.pack('hhll', fcntl.F_WRLCK, 0, 0, 0, 0)
try:
fcntl.fcntl(fd, fcntl.F_SETLK, lock_data)</p><h1>✅ 此时已持锁，可安全操作共享资源</h1><pre class='brush:python;toolbar:false;'>with open('/tmp/data.txt', 'a') as f:
f.write('written by pid {}\n'.format(os.getpid()))except OSError as e: if e.errno == 11: # EAGAIN print("Lock held by another process") raise
注意：不要在这里 os.close(fd)，否则锁立即释放
- 锁文件本身可以是空文件，甚至不存在——
os.open(..., O_CREAT)会创建它 - 进程退出时，内核自动释放所有fd上的锁，无需显式解锁（但主动
fcntl.F_UNLCK更清晰） - 若需重入锁（同一进程多次加锁），需确保复用同一个fd，不能重复
os.open
为什么锁住文件后其他进程仍能write()成功？
因为fcntl锁是**强制锁但非I/O拦截锁**：它只在进程调用read()/write()前由内核检查，如果对方绕过Python层直接用C库write(2)、或用shell重定向echo "x" > file，内核仍会拒绝——但前提是对方也用了fcntl或flock尝试加锁。如果完全不加锁就写，内核不会阻止。
换句话说：fcntl锁只对“也遵守锁协议”的进程生效，它不是文件系统级别的写保护。
- 没有机制能阻止一个恶意进程
rm -f锁文件（但删文件不影响已有fd的锁） - 若多个进程用不同路径指向同一inode（硬链接），锁依然有效，因为锁基于inode而非路径
- 容器或namespace环境下，需确认所有进程共享同一挂载命名空间，否则锁可能不互通
锁的有效性完全依赖于所有参与者都主动调用fcntl.fcntl()申请锁——它不提供透明拦截，也不替代应用层协调逻辑。
