php文件锁必须用flock()，因fopen()模式不提供原子互斥；flock()是跨进程内核级建议锁，需在i/o前获取并检查返回值，linux下锁基于inode，重命名会导致失效；高并发需非阻塞+超时重试；日志场景可用error_log()替代；分布式环境应选redis分布式锁。
PHP 文件锁必须用 flock()，fopen() 的模式参数不提供原子级互斥
很多人误以为用 fopen($file, 'c') 或 'a+' 就能避免并发冲突，其实不能。这些模式只控制打开方式和指针位置，不阻塞其他进程对同一文件的读写。flock() 才是唯一跨进程生效的内核级 advisory lock（建议性锁），且必须配合文件句柄使用。
典型错误写法：fopen($file, 'c+'); fwrite($fp, $data); —— 没调用 flock()，多进程同时执行时必然丢数据。
- 锁必须在
fopen()之后、任何 I/O 操作之前获取，且推荐用LOCK_EX（写锁）或LOCK_SH（读锁） - 务必检查
flock()返回值：false表示加锁失败（如被其他进程占用），不能忽略 - 锁在
fclose()时自动释放，但更安全的做法是显式调用flock($fp, LOCK_UN) - Linux 下锁基于 inode，重命名/覆盖文件会导致锁失效；不要在锁期间
rename()或unlink()原文件
flock() 在高并发下会阻塞，非阻塞模式要主动处理超时
默认 flock($fp, LOCK_EX) 是阻塞的：如果锁被占，当前请求会一直等下去，可能拖垮整个 PHP-FPM worker。生产环境必须设超时，但 PHP 原生不支持 flock() 超时参数，得自己轮询。
- 用
flock($fp, LOCK_EX | LOCK_NB)启用非阻塞模式，失败立即返回false - 手动实现最多尝试 N 次、每次 sleep 微秒级（如
usleep(50000)），总耗时控制在 100ms 内 - 超过重试次数应放弃并返回错误（如 HTTP 503），而不是死等或降级为无锁写入
- 注意：
LOCK_NB在 Windows 下部分版本有兼容问题，建议 Linux 环境优先验证
日志类场景可用 error_log() 替代文件锁，但仅限追加写
如果只是记录日志（append-only），error_log($msg, 3, $file) 是更轻量的选择。它底层调用系统 write()，在多数 Unix 系统中对单次 write() 是原子的（只要内容 ≤ PIPE_BUF，通常是 4KB），且无需手动管理锁。
立即学习“PHP免费学习笔记（深入）”；
- 适用场景：纯文本日志、JSON 行日志、监控埋点等“只追加、不修改”的写入
- 不适用：需要读取 + 修改 + 写回的场景（如计数器、配置缓存更新）
- 注意
error_log()不支持自定义文件权限，需提前用chmod()设好 - 若日志量极大（如每秒万级），仍建议切到 Redis 或消息队列，避免磁盘 I/O 成瓶颈
替代方案：用 Redis 实现分布式锁比文件锁更可靠
当业务跨多台 Web 服务器，或文件系统是 NFS/Ceph 等不完全支持 flock() 的共享存储时，文件锁会失效。此时应放弃文件锁，改用 Redis 的 SET key value EX seconds NX 做分布式锁。
- 关键点：value 必须是唯一标识（如
uniqid('', true)），释放锁时用 Lua 脚本比对 value 再DEL，防止误删 - 锁过期时间（EX）必须大于业务最大执行时间，并预留缓冲（如设为 3×预估耗时）
- Redis 单点故障会影响锁服务，生产环境建议用 Redis Sentinel 或 Cluster
- 别用 MySQL 表锁或 MyISAM 行锁做高并发锁——性能差、死锁风险高、连接数易打满
文件锁不是银弹。真正棘手的是“读-改-写”这类操作，哪怕用了 flock()，逻辑层仍可能因异常中断导致锁残留或数据不一致。最稳妥的方式，是把这类状态变更收敛到原子化服务（如用 Redis INCR、MySQL SELECT FOR UPDATE 配合事务），而非依赖文件 + 锁的组合。
