不能直接批量锁定多个文件；flock()仅作用于单个已打开的文件句柄，批量场景需按统一顺序循环加锁、全部成功才执行操作，任一失败须立即释放已持锁并中止，且必须使用非阻塞模式（LOCK_EX | LOCK_NB）配合显式错误处理与超时退避。
PHP 中 flock() 能否用于批量文件锁定？
不能直接“批量”锁定多个文件——flock() 是对单个文件描述符的 advisory 锁，每次调用只作用于一个打开的文件句柄。所谓“批量锁定”，本质是循环对每个文件单独加锁，且必须注意加锁顺序和超时控制，否则极易死锁或阻塞。
常见错误现象：flock() 返回 false 却没检查原因；多个进程按不同顺序尝试锁定 file_a.txt 和 file_b.txt，导致互相等待；用 LOCK_EX | LOCK_NB 但没处理失败重试逻辑。
- 加锁前务必用
fopen($path, 'c')或'r+'打开文件（避免因文件不存在导致fopen失败，进而flock无句柄可锁） - 所有文件应按统一路径排序（如
sort($files, SORT_STRING)），强制加锁顺序一致，规避死锁 - 使用
LOCK_EX | LOCK_NB非阻塞模式，失败立即退出或退避重试，不要无条件LOCK_EX - Windows 下
flock()对 NFS 挂载点可能失效，生产环境需验证
如何安全地批量加锁并执行操作？
核心是「全部成功才执行，任一失败就释放已锁文件并中止」。不能边锁边处理，否则部分失败时状态不一致。
示例场景：批量更新一组配置文件，要求全部原子性生效。
立即学习“PHP免费学习笔记（深入）”；
$files = ['config/a.json', 'config/b.json', 'config/c.json'];
sort($files); // 强制顺序
$handles = [];
foreach ($files as $path) {
$fp = fopen($path, 'c+');
if (!$fp || !flock($fp, LOCK_EX | LOCK_NB)) {
// 清理已获取的锁
foreach ($handles as $h) {
flock($h, LOCK_UN);
fclose($h);
}
throw new RuntimeException("Failed to lock {$path}");
}
$handles[] = $fp;
}
// 全部锁定成功，开始业务逻辑
try {
foreach ($files as $i => $path) {
file_put_contents($path, json_encode($newData[$i]));
}
} finally {
// 统一解锁
foreach ($handles as $h) {
flock($h, LOCK_UN);
fclose($h);
}
}
flock() 的锁在什么情况下会自动释放？
锁生命周期严格绑定于文件指针资源（resource），不是文件路径。只要 PHP 进程结束、或显式调用 fclose() / flock($fp, LOCK_UN)，锁就释放。没有“过期自动释放”机制。
- 脚本异常崩溃（如
exit()、致命错误）时，PHP 会自动关闭所有打开的文件句柄，锁随之释放——这是flock()安全性的基础 - 不能依赖
register_shutdown_function()做解锁兜底：若进程被kill -9，该函数不会执行 - 子进程继承父进程的文件描述符，但
flock()锁不继承；父子进程对同一文件句柄调用flock()会相互影响 - Web SAPI（如 FPM）中，请求结束即释放锁；CLI 脚本需确保正常退出流程覆盖所有
fclose()
替代方案：为什么有时该放弃 flock()？
当文件跨机器共享（NFS/Samba）、或需跨语言协作（如 Python 脚本也要读写同一批文件）时，flock() 基本不可靠——它依赖本地内核的文件描述符锁，不保证分布式一致性。
此时更务实的做法是引入外部协调机制：
- 用 Redis 的
SET key value NX EX 30实现带 TTL 的分布式锁，锁名可基于文件路径哈希生成 - 在文件同目录下创建
.lock临时文件，配合mkdir()原子性（仅当目录不存在时创建成功）模拟锁，需自行清理和超时检测 - 改用数据库事务管理文件操作元信息（如“这批文件正在更新中”状态），把文件 I/O 当作最终落地步骤
真正麻烦的从来不是怎么加锁，而是想清楚：锁的边界是否真能覆盖所有并发入口。比如 cron 脚本 + Web 请求同时操作同一组文件，flock() 只拦得住 PHP 进程，拦不住 shell 命令。
