flock()返回true但并发写仍混乱，根本原因是锁未在同一个文件描述符上持续持有；PHP的flock()是建议性锁，仅对当前$fp有效，一旦$fp关闭或销毁锁即释放。
为什么flock()返回true但并发写还是乱了
根本不是锁没起作用，而是你没在同一个文件描述符上持续持有锁。PHP的flock()是建议性锁，只对当前$fp有效——一旦$fp被fclose()、被垃圾回收、或函数返回后局部变量销毁，锁立刻释放。很多封装成函数的写法（比如isRunning()）在return前就丢了句柄，等于“加了锁又马上解锁”，其他进程当然能抢入。
常见错误现象：
-
flock($fp, LOCK_EX | LOCK_NB)返回true，但紧接着写入时仍发生覆盖 - 本地开发正常，一上K8s或NFS环境就出问题
- 脚本A加锁后sleep(5)，脚本B立刻也能
flock()成功
关键检查点：
- 确保
$fp在整个需要互斥的逻辑执行期间**始终存活**，不能是函数内临时变量 - 不要用
file_put_contents($file, $data, FILE_APPEND)替代手动fwrite()+flock()，它不带锁 - 加锁前调用
clearstatcache()，尤其在NFS或overlay2挂载下，避免缓存导致fopen()误判文件状态 - 统一用
fopen($file, 'c+')或'w+'打开锁文件，确保可读可写且不截断 - 避免用
'a'（追加模式），它内部会移动文件指针到末尾，影响flock()行为一致性 - 如果只是做“存在性标记”，也别用
'w'——它会清空内容，导致其他进程读不到锁标识；用'c+'更安全 - 锁文件权限设为
0644，防止worker因umask不同打不开文件 - 误以为
LOCK_SH能阻止其他进程写——它只阻止其他进程加LOCK_EX，不阻止LOCK_SH或无锁写入 - 混合使用
LOCK_EX和LOCK_SH时，没注意谁在等谁：一个进程持LOCK_SH，另一个请求LOCK_EX会被阻塞；但第三个再请求LOCK_SH仍能成功 - 非阻塞模式下漏判
$wouldBlock：必须传第三个参数并检查其值，flock($fp, LOCK_EX | LOCK_NB)返回true不代表拿到锁，可能只是没阻塞就返回了 - 单机跑10个进程并发测试全正常，部署到K8s StatefulSet就频繁冲突
- 锁文件明明存在且
flock()返回true，但日志里看到两个进程同时写入同一行 -
strace -e trace=flock php script.php发现系统调用返回0（成功），但业务仍错乱 - 把锁文件放在
/tmp（宿主机本地路径），通过volume挂载进容器 - 改用Redis的
SET key value NX EX 30实现分布式锁，绕过文件系统限制 - 确认NFS挂载选项含
nolock？有就去掉；没有的话，别信文档，实际测
fopen()模式选错会导致flock完全无效
flock()能否生效，和fopen()打开方式强相关。最典型错误：用'r'或'w'打开后直接flock()，结果锁不了——因为某些系统要求文件描述符必须有写权限才能加排他锁（LOCK_EX）。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
LOCK_EX vs LOCK_SH：写场景下用错类型等于没锁
并发写入必须用LOCK_EX（排他锁）。用LOCK_SH（共享锁）只能防读冲突，多个进程同时LOCK_SH是允许的，写操作照样并发撞车。
容易踩的坑：
Docker/NFS环境下flock()为什么看起来“随机失效”
根本原因不是PHP问题，而是底层存储不支持POSIX文件锁语义。Docker默认用overlay2驱动，NFSv3及更早版本根本不保证flock()跨节点一致；即使NFSv4.2启用minorversion=2，生产环境兼容性极差。
判断是否掉进这个坑：
临时缓解办法（不推荐长期用）：
真正难处理的是锁粒度和生命周期——一旦你开始考虑“锁超时自动续期”“跨机器锁迁移”“锁持有期间进程崩溃”，说明flock()已经不是解法，而是问题本身。
