flock() 必须作用于 fopen() 打开的文件句柄，不能直接对路径调用；需注意模式选择、跨平台限制、阻塞/非阻塞行为、锁类型区别、显式解锁、cli/web 差异及进程继承问题。
用 flock() 加锁前必须打开文件句柄
很多人直接对路径调用 flock()，结果返回 false 还以为函数坏了。其实 flock() 只作用于已打开的资源（Resource），不是文件路径。
- 必须先用
fopen()打开文件，且模式不能是只读（'r'）——写入场景下推荐'c+'（不截断、可读写、不存在则创建） - 如果文件只是用来同步信号、不存数据，用
fopen('/tmp/lockfile', 'c')配合flock()更轻量 - 注意：windows 下
flock()在 NFS 或某些网络文件系统上可能失效，别在跨平台分布式环境里依赖它
flock() 的阻塞与非阻塞行为怎么选
默认 flock($fp, LOCK_EX) 是阻塞的——其他进程会卡住直到锁释放。线上服务里这容易拖垮请求响应时间。
- 加
LOCK_NB实现非阻塞：例如flock($fp, LOCK_EX | LOCK_NB)，失败时立刻返回false，你自己决定重试、降级或报错 - 不要在循环里无休止
usleep()等锁，容易积压；建议最多 3 次尝试 + 指数退避 -
LOCK_SH（共享锁）和LOCK_EX（独占锁）不能共存，但多个LOCK_SH可以同时存在——适合“读多写少”的缓存更新场景
解锁时机不对，锁就形同虚设
php 脚本结束时会自动释放 flock()，但这不等于安全。一旦中间 exit、die、未捕获异常或超时中断，锁可能没机会显式释放。
- 务必在业务逻辑结束后调用
flock($fp, LOCK_UN)，哪怕后面还有其他操作 - 把
flock()和fclose()放进try...finally块里最稳妥（PHP 7.0+） - 别指望
register_shutdown_function()来兜底——它不保证在所有异常路径下都执行，尤其是致命错误 - 注意：
fclose()会隐式释放锁，但别依赖它，因为文件句柄可能被复用或提前关闭
为什么 flock() 在 CLI 和 Web SAPI 下表现不一致
常见现象：CLI 脚本里锁好使，Web 请求里却频频冲突。根本原因是 PHP-FPM 或 apache 的进程模型让文件句柄生命周期变复杂。
立即学习“PHP免费学习笔记（深入）”；
- Web 环境中，每个请求是独立进程/线程，
flock()是进程级的，没问题；但如果你用opcache.file_cache或 APCu 缓存了句柄变量，可能导致锁对象复用异常 - 更隐蔽的问题：nginx + PHP-FPM 下，如果启用了
fastcgi_finish_request()，后续异步逻辑里再操作文件锁，句柄可能已被回收 - 调试时用
lsof -p $PID | grep your_lock_file查看当前进程是否还持有句柄，比猜更可靠
锁本身不难，难的是它藏在流程深处——比如一个日志写入函数里加了锁，但调用它的上层函数又做了 pcntl_fork()，子进程会继承句柄和锁状态，这时候 flock() 就不再按你预期工作了。