flock()必须作用于原文件句柄以保护“读-改-写-重命名”整段逻辑，因rename仅原子替换文件名，不保证前置操作的并发安全；锁需覆盖从读取原文件到rename完成的全过程，且必须用fopen打开原文件后调用flock，不可直接锁路径或临时文件。
flock() 不能直接锁住“替换动作”，只能锁住打开的文件句柄；真正要保护的是“读-改-写-重命名”这一整段逻辑，否则 rename 本身虽原子，但前面读取或写入仍可能并发错乱。
为什么单纯 rename + flock 不够安全
很多人以为用 rename() 替换文件天然原子，就不用锁——这是常见误解。rename 确实是原子的，但它只保证“旧文件名指向新内容”这一步不可中断；而你替换前的读取、临时文件写入、JSON 解码/拼接等操作，全在锁外发生，照样会并发冲突。
比如两个请求同时执行：file_get_contents('config.json') → 修改数组 → file_put_contents('config.tmp') → rename('config.tmp', 'config.json')。若两者几乎同时读，就会基于同一份旧数据修改，后写者覆盖前者，丢数据。
- 锁必须包裹整个业务逻辑起点（如读取原文件）到终点（如 rename 完成）
- 临时文件本身不需加锁，但它的生成和写入必须在主文件锁持有期间完成
- 别对
'config.tmp'调用flock()——它不是同步目标，锁的是原文件的访问权
正确加锁位置：锁原文件句柄，不是锁路径
flock() 必须作用于 fopen() 打开的句柄，且该句柄对应的是你要协调访问的**那个原文件**（如 'config.json'），哪怕你只是读它、不写它。
典型错误写法：flock('/tmp/lock', LOCK_EX) —— 直接传路径，永远返回 false；正确做法是打开原文件（哪怕只读），再锁它：
$fp = fopen('config.json', 'r');
if (!$fp || !flock($fp, LOCK_SH | LOCK_NB)) {
throw new RuntimeException('无法获取读锁');
}
// 此时可安全 file_get_contents('config.json')
$data = json_decode(file_get_contents('config.json'), true);
flock($fp, LOCK_UN);
fclose($fp);
- 用
LOCK_SH即可读取，多个进程可共存；写入时才升为LOCK_EX - 务必加
LOCK_NB避免阻塞，尤其 Web 请求里卡住几秒就超时 - 即使只读也要锁——否则“读取”和“另一个进程的写入”就失去顺序保障
原子替换 + 文件锁的标准组合流程
核心是：先锁原文件 → 读取 → 写临时文件 → rename → 解锁。整个过程串行化，中间无间隙。
$lockFile = 'config.json';
$fp = fopen($lockFile, 'c+'); // 'c+'：存在则打开，不存在则创建，不截断
if (!$fp || !flock($fp, LOCK_EX | LOCK_NB)) {
throw new RuntimeException('获取独占锁失败');
}
try {
$content = file_get_contents($lockFile);
$data = $content ? json_decode($content, true) : [];
$data['updated_at'] = time();
$tmpFile = $lockFile . '.tmp.' . getmypid();
file_put_contents($tmpFile, json_encode($data));
rename($tmpFile, $lockFile); // 原子替换
} finally {
flock($fp, LOCK_UN);
fclose($fp);
}
-
fopen('config.json', 'c+')比'r+'更稳妥：避免文件不存在时报错，也避免'w+'截断风险 - 临时文件名带
getmypid()是防止单机多进程写同一个.tmp名冲突 -
finally块确保锁一定释放，哪怕中间throw或exit - 别省略
flock($fp, LOCK_UN)——依赖fclose()隐式释放太危险
Web 环境下容易被忽略的坑
CLI 脚本能跑通的锁逻辑，在 PHP-FPM 下常失效，问题往往不在 flock() 本身，而在运行上下文。
- Nginx + PHP-FPM 中，若用了
fastcgi_finish_request()，后续异步操作里的flock()可能因句柄提前关闭而失败 - OPcache 启用
opcache.file_cache时，可能缓存了旧的文件句柄变量，导致锁对象复用异常 - 调试时别只看代码逻辑，用
lsof -p $(pgrep -f 'php.*your_script') | grep config.json实时确认锁是否真被当前进程持有 - Windows 下 NFS 共享盘、Docker volume 绑定挂载点等场景，
flock()可能完全失效——这时得切 Redis 分布式锁
锁本身很简单，难的是它藏在流程深处：比如一个日志函数里加了锁，但调用它的上层逻辑又开了多线程或异步任务，锁就形同虚设。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
