PHP 多进程写同一文件怎么使用排他锁

多个 PHP 进程同时改写同一个文本文件时，真正要保护的不是某一行 fwrite()，而是“打开、定位、写入、刷新”这一整段临界区。实用做法是让读写方约定同一个独立锁文件，写入方用 flock($lock, LOCK_EX)，拿锁后再操作数据文件；不要直接用 w 或 w+ 打开数据文件后才想起加锁。

结论是：PHP 多进程写同一文件，应先打开同一个锁文件并取得 LOCK_EX，再在锁内完成完整写入，最后刷新、解锁并关闭句柄。flock 是协作式锁，所有访问方都必须遵守这套协议。

先把写入协议定成“同一个锁对象”

flock 的锁附着在文件指针上，但它保护的是“使用同一锁对象的协作方”。如果进程 A 锁住 report.lock，进程 B 却只调用 file_put_contents() 写 report.txt，B 并不会自动被拦住。因此锁文件路径必须固定，写入、读取和定时任务都要使用相同路径。

下面这张表先把接口语义定清楚。这样调用方遇到等待、失败或读取时，不会把不同问题混在一起。

flock 的参数怎么对应读写职责

写入方使用 LOCK_EX，同一时刻只允许一个遵守协议的写入者进入临界区。读取方若想避开“读到覆盖一半的内容”，也不能只调用 file_get_contents；它应先对同一个锁文件申请 LOCK_SH。共享锁之间可以并存，但会与排他锁互斥。

锁的生命周期由文件指针决定。把持锁的变量改成别的值、提前关闭句柄，都会让保护范围结束，所以不要在拿锁后把句柄丢掉，也不要把真正的写入动作放到锁外。

写入时为什么不能先用 w 模式清空

fopen($dataPath, 'w') 和 w+ 的一个危险点是：打开时就可能把数据文件截断为零字节，此时排他锁还没有取得。另一个进程可能正好在这个空窗期读取，或者它拿到锁后又把自己的内容覆盖掉。覆盖式写入可以先用 c+ 打开，成功取得锁后再调用 ftruncate。

完整写入还要考虑 fwrite 的返回值。它可能只写入部分字节，因此示例用循环写完，再调用 fflush，最后才解锁：

这里的关键不是把锁文件当成数据文件，而是让它成为所有访问方都认同的“门”。如果业务是追加日志，可以把数据文件改成 a 或 a+，但仍然要把追加动作放在 LOCK_EX 内。

非阻塞、异常和读取方怎么配合

默认的 LOCK_EX 会等待，适合不能丢更新的后台任务；Web 请求不希望长时间占用进程时，可以使用 LOCK_NB。第三个参数用来区分“暂时有人持锁”和“加锁调用本身失败”：

读取方可以申请共享锁后再读取。注意它必须锁住同一个 report.lock，而不是对 report.txt 另起一套路径：

这套方式仍然是 advisory locking（协作式锁），不是强制所有程序停下来的系统级防护。外部脚本、其他语言进程或人工编辑器如果完全不调用 flock，它们仍可能绕过协议。跨网络文件系统、线程化服务器 API 和 Windows 文件行为也要单独做兼容测试；不能因为本机 Linux CLI 进程工作正常，就推断所有运行环境都相同。

常见问题

只给 fwrite 加 LOCK_EX 可以吗？

不够。定位、截断、写入和刷新共同决定文件状态，锁应覆盖完整临界区，而不是只包住一行写调用。

拿不到 LOCK_NB 应该一直 while 重试吗？

不一定。短任务可以退避重试，Web 请求更适合返回“稍后再试”或进入队列；同时要先区分 would_block 与句柄无效等真实错误。

关闭数据句柄后还要 LOCK_UN 吗？

建议显式调用 LOCK_UN，并在最后 fclose。这样代码的保护范围清楚，异常路径也更容易审查。

file_get_contents 会自动等写入完成吗？

不会。它只有在读取方也申请同一个锁文件的 LOCK_SH，且写入方遵守同一协议时，才有协作式的等待关系。

PHP 官方手册中的 flock 说明、fopen 模式和 fwrite 返回值可以作为参数和边界的进一步依据。落地时先统一锁文件路径，再缩短临界区，最后为写失败、锁竞争和句柄关闭分别留下可观察的日志。