flock本质是文件描述符级互斥锁，仅保证单进程执行，无法实现n路限流；需用redis或信号量替代，并注意绝对路径、非阻塞标志、异常释放等细节。
PHP用flock做并发限制，本质是靠文件句柄加锁，不是“限流”
它不控制请求数量，只保证同一时刻最多一个进程能执行某段代码。想实现“最多5个请求同时处理”，flock做不到，得换信号量或Redis计数。
常见错误现象：flock返回true但逻辑仍被并发穿透——多半是没检查返回值，或锁文件被意外关闭/重命名。
- 必须用
fopen(..., 'c')打开锁文件，'c'确保文件存在且不会清空内容，也避免fopen失败时静默跳过 - 加锁前要
clearstatcache()，尤其在NFS或某些容器环境下，文件状态缓存可能导致flock误判 - 锁文件路径不能写相对路径，比如
'./lock.txt'，不同worker工作目录可能不同，要用绝对路径，如/tmp/myapp.lock
flock阻塞 vs 非阻塞：选错就卡死整个请求
默认flock($fp, LOCK_EX)会一直等，直到拿到锁。高并发下，大量PHP-FPM进程挂起在flock调用上，CPU不高但响应全堵住。
使用场景：后台任务（如定时脚本）可接受等待；Web接口必须用非阻塞+降级逻辑。
- 加
LOCK_NB标志：flock($fp, LOCK_EX | LOCK_NB)，失败立即返回false - 不要裸写
if (!flock(...)) { die(); }，应配合重试次数、随机延迟、或直接返回“服务繁忙” - 注意：
flock的非阻塞在Windows上行为不一致，生产环境务必在Linux验证
锁文件生命周期管理：删错或忘删都会出问题
锁文件本身只是载体，flock锁的是文件描述符，不是文件名。所以unlink()锁文件不影响已持有的锁，但fclose()会自动释放。
容易踩的坑：fopen后没fclose，或脚本异常退出导致句柄未释放，锁就永远挂着。
- 务必在
try...finally里关文件：即使中间return或throw，也能保证fclose - 不要手动
unlink()锁文件——除非你确认所有进程都已退出且不再需要该锁 - 锁文件权限设为
0644，避免因权限问题导致部分worker无法打开
替代方案比硬扛flock更靠谱的几个信号
当发现要反复处理“锁超时”“重试策略”“跨机器失效”这些问题时，说明flock已经超出适用边界。
真实项目中，以下情况建议直接切走：
- 部署在多台服务器上 →
flock完全失效，改用Redis::setex()+ Lua原子操作 - 需要精确控制并发数（如限3个）→ 用
sem_acquire()（需sysvsem扩展）或Redis的INCR/DECR - 锁持有时间超过1秒 → 检查是不是锁粒度太大，应该拆成多个小锁，而不是加大超时容忍度
最常被忽略的一点：flock锁不住命令行脚本和Web请求之间的竞争。比如php cron.php和nginx跑的index.php如果用同一个锁文件，得确保它们用的是同一个用户、同个PHP SAPI（CLI和FPM的文件描述符不共享），否则锁根本不起作用。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
