fcntl.flock() 会失败，因为 flock() 不属于 fcntl 模块，而是 os 模块的函数（os.flock()）；fcntl 模块仅提供 fcntl.fcntl() 等底层 posix 锁接口，需手动构造 struct flock 并调用 f_setlk 等命令。
为什么 fcntl.flock() 在 Linux 上会失败？
Linux 下真正靠 fcntl 做文件锁，得用 fcntl.fcntl() 配合 fcntl.F_SETLK 等底层命令，不是 flock() —— 后者是封装过的系统调用，跟 fcntl 模块无关，也**不走 fcntl 接口**。很多初学者一查文档就直接写 flock(fd, LOCK_EX)，结果报 AttributeError: module 'fcntl' has no attribute 'flock'。
根本原因是：flock() 是 os 模块的函数（os.flock()），而 fcntl 模块只提供原始的 fcntl() 系统调用封装。
- 想用
fcntl做 POSIX 锁：必须手动构造struct flock并传给fcntl.fcntl(fd, fcntl.F_SETLK, flock_struct) - 想简单加锁：直接用
os.flock()，它更轻量、语义清晰，且在 Linux 上行为稳定 -
fcntl.fcntl()要求文件描述符是打开的（不能是 Python 的file对象，得用.fileno()）、且文件系统需支持 POSIX 锁（ext4、XFS 可以，NFSv3/v4 有坑，/proc /sys 不支持）
如何用 fcntl.fcntl() 实现非阻塞写锁？
POSIX 锁支持读锁（F_RDLCK）、写锁（F_WRLCK）和解锁（F_UNLCK），且可设为阻塞或非阻塞。非阻塞对服务进程很关键，避免因锁等待拖垮整个流程。
实操要点：
- 先用
open(path, 'r+')获取可读写 fd，再调用.fileno() - 构造 bytes 类型的
struct flock：前 8 字节是锁类型（int.to_bytes(2, 'little')），接着 8 字节起始偏移（0 表示全文件），8 字节长度（0表示到 EOF），最后 4 字节 PID（可填 0）——但更稳妥是用array.array('h', [...])或ctypes，不过多数场景直接用os.flock()更省事 - 非阻塞写锁调用：
fcntl.fcntl(fd, fcntl.F_SETLK, flock_bytes)；若失败会抛OSError并带errno == errno.EAGAIN或errno.EACCES - 别忘了
import fcntl, errno, array
简例（仅示意结构，生产环境建议用 os.flock()）：
import fcntl, errno, array
fd = open('/tmp/test.lock', 'w+').fileno()
# 构造 flock: type=2(WRLCK), whence=0(SEEK_SET), start=0, len=0, pid=0
fl = array.array('h', [2, 0, 0, 0, 0, 0])
try:
fcntl.fcntl(fd, fcntl.F_SETLK, fl)
except OSError as e:
if e.errno in (errno.EAGAIN, errno.EACCES):
print("锁已被占用")
else:
raise
os.flock() 和 fcntl.fcntl() 锁能互相感知吗？
能。Linux 内核层面，os.flock()（对应 flock(2) 系统调用）和 fcntl.fcntl(..., F_SETLK)（对应 fcntl(2)）操作的是同一套内核锁表，互斥生效。一个进程用 os.flock(fd, os.LOCK_EX) 加了写锁，另一个进程用 fcntl.F_SETLK 尝试加锁就会失败。
但注意边界情况：
- 锁粒度不同：
os.flock()总是对整个文件加锁；fcntl锁可指定字节范围（l_start+l_len），范围锁之间可能不冲突 - 继承行为不同：子进程默认继承
os.flock()锁（除非加LOCK_NB），而fcntl锁默认不继承（除非显式设置FD_CLOEXEC外的标志） - 释放时机：两者都随 fd 关闭自动释放，但若用
os.dup()复制 fd，os.flock()锁会被复制的 fd 共享，而fcntl锁不会
在 NFS 文件系统上用 fcntl 锁为什么总是失效？
NFSv3 默认不支持 POSIX 锁（fcntl 锁），服务器端需启用 nfslock 服务（即 rpc.statd + rpc.lockd），客户端挂载时加 local_lock=all 或 nofail 参数才可能回退到本地模拟。NFSv4 原生支持，但要求内核 ≥ 2.6.12 且 export 配置正确。
真实问题表现：
- 锁调用成功返回，但其他机器完全不受影响（伪成功）
- 锁在客户端崩溃后不自动释放（因为没经过 server 协调）
-
strace可见fcntl()系统调用返回 0，但实际无互斥效果
对策很直接：除非明确控制 NFS 服务端配置并做过压测，否则别在 NFS 上依赖 fcntl 或 os.flock() 做关键同步。改用基于文件原子性的方案（如 os.open(..., os.O_CREAT | os.O_EXCL) 创建临时锁文件）更可靠。
复杂点在于：锁机制本身是内核功能，但跨网络时依赖用户态守护进程协同；一旦 rpc.statd 挂掉或网络分区，锁状态就不可信——这种隐式依赖，很容易被忽略。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
