PHP用flock()锁文件时为啥没生效
根本原因通常是没检查返回值，或者锁类型选错了。PHP的flock()是建议性锁（advisory），不是强制锁——所有进程都得主动调用它、检查返回值，否则等于没锁。
常见错误现象：flock()返回true但其他进程照样写入；脚本退出后锁没释放；CLI和Web请求之间互不感知。
- 必须用
flock($fp, LOCK_EX)加排他锁，LOCK_SH只防写不防读，不适合写保护场景 - 加锁前确保
fopen()成功且文件以'c'或'r+'等可写模式打开（'r'模式下LOCK_EX会失败） - 锁只在文件描述符生命周期内有效，
fclose()或脚本结束自动释放，别依赖flock($fp, LOCK_UN)显式解锁——万一抛异常就漏了 - Web服务器多进程/多线程下，不同请求可能拿到不同
$fp，但只要都操作同一文件路径+正确调用flock()，内核级锁机制就能协同
多个PHP进程同时写同一个日志文件怎么避免覆盖
直接追加写+flock()是最轻量解法，比数据库或消息队列更贴合日志场景。关键不在“锁整个文件”，而在“锁住写入动作那一小段”。
使用场景：定时脚本+Web接口共用一个app.log，不希望某次fwrite()把另一进程刚写的内容冲掉。
立即学习“PHP免费学习笔记（深入）”；
- 打开文件用
fopen('app.log', 'a')（追加模式），天然定位到末尾，避免fseek()干扰 -
flock($fp, LOCK_EX)后再fwrite()，写完立即fflush($fp)确保刷到磁盘，再fclose() - 别用
file_put_contents($file, $data, FILE_APPEND)代替——它内部没做flock()，并发时仍可能错乱 - 如果日志量极大，考虑按小时分文件（如
app-20240515-14.log），减少单文件争抢
flock()在NFS或Docker容器里为什么失效
因为flock()依赖本地文件系统内核支持，NFSv3及更早版本不保证锁语义，Docker默认存储驱动（overlay2）对flock()的支持也受限于宿主机内核和挂载选项。
典型错误现象：本地测试正常，一上生产（NFS共享存储）或容器化部署就出现并发写冲突。
- 先确认是否真在NFS上：运行
mount | grep nfs，若看到nfs或nfs4，基本可判定flock()不可靠 - Docker中优先把文件存在
/tmp或挂载tmpfs卷（内存盘），这些是本地ext4/xfs，flock()有效 - 跨机器协调必须换方案：用Redis的
SET key value NX EX 30实现分布式锁，或改用数据库行锁 - Linux 5.10+启用NFSv4.2并挂载时加
minorversion=2可支持flock()，但兼容性差，不推荐业务强依赖
PHP写配置文件时如何防止写到一半被其他进程读到脏数据
核心思路不是“锁住读”，而是“让写变成原子操作”——先写临时文件，再rename()覆盖原文件。Linux下rename()是原子的，且新文件权限/内容一次性生效。
这比全程flock()更安全：避免读进程因等锁超时而读到旧数据，也绕过锁失效风险。
- 生成配置时写入
$tmp = tempnam(sys_get_temp_dir(), 'cfg_')，完成后chmod($tmp, 0644) - 用
rename($tmp, $real_config_path)替换原文件——成功即生效，失败则保留原配置 - 读配置的代码完全不用
flock()，直接file_get_contents()或include()，因为rename()后旧文件句柄自动失效，新内容已完整 - 注意：不要用
copy()+unlink()，这两步非原子，中间可能被读进程抓到空文件或半截内容
真正麻烦的是锁粒度——你以为锁一个文件就够了，但实际要区分“谁在读”“谁在写”“是否跨存储介质”。很多问题不是flock()不好用，而是没想清楚它到底锁住了什么。
