php 是同步执行的，但多个 http 请求会并行运行在不同进程/线程中，因此不加控制地读-改-写 json 文件极易导致后写入者覆盖先写入者的修改，引发数据丢失。本文详解文件锁（flock）机制与数据库替代方案，助你构建安全的配置更新逻辑。
php 是同步执行的，但多个 http 请求会并行运行在不同进程/线程中，因此不加控制地读-改-写 json 文件极易导致后写入者覆盖先写入者的修改，引发数据丢失。本文详解文件锁（flock）机制与数据库替代方案，助你构建安全的配置更新逻辑。
在 Web 应用中，当多个用户同时调用 updateConfig() 这类“读取 → 修改 → 写入”三步操作时，即使 PHP 本身是单线程同步执行，每个 HTTP 请求仍由独立的 PHP 进程（或 FPM worker）处理，它们彼此隔离、并发运行。这意味着：
- 用户 A 打开并读取 config.json（得到旧数据）；
- 用户 B 几乎同时打开并读取同一文件（也得到相同旧数据）；
- 用户 A 修改后写入文件；
- 用户 B 基于过期的原始数据完成修改，并覆盖写入——用户 A 的变更被静默丢弃。
这就是典型的 Race Condition（竞态条件），并非 PHP 异步所致，而是共享资源（文件）缺乏访问协调机制。
✅ 正确做法：使用 flock() 实现文件级排他锁
PHP 提供了轻量、可靠的 flock() 系统调用，可在写入前获取独占锁，确保同一时刻仅一个进程可执行写操作：
function updateConfig(array $newSettings): bool {
$configPath = 'config.json';
// 以可读写方式打开（注意：必须用 'c+' 或 'w+'，'r+' 不支持 flock 写锁）
$fp = fopen($configPath, 'c+');
if (!$fp) {
throw new RuntimeException("无法打开配置文件: $configPath");
}
// 尝试获取阻塞式独占锁（LOCK_EX），超时 5 秒避免永久等待
$startTime = time();
while (!flock($fp, LOCK_EX | LOCK_NB)) {
if (time() - $startTime > 5) {
fclose($fp);
throw new RuntimeException("获取文件锁超时，请稍后重试");
}
usleep(100000); // 等待 100ms 后重试
}
try {
// 安全读取当前内容（锁已持有，其他进程无法写入）
fseek($fp, 0);
$content = stream_get_contents($fp);
$config = $content ? json_decode($content, true) : [];
// 合并新设置（示例：深度合并或简单覆盖）
$config = array_replace_recursive($config, $newSettings);
// 清空文件并写入新 JSON（保持原子性）
ftruncate($fp, 0);
rewind($fp);
$json = json_encode($config, JSON_UNESCAPED_UNICODE | JSON_PRETTY_PRINT);
fwrite($fp, $json);
fflush($fp); // 强制刷入磁盘
return true;
} finally {
// 无论成功失败，务必释放锁
flock($fp, LOCK_UN);
fclose($fp);
}
}⚠️ 关键注意事项：
立即学习“PHP免费学习笔记（深入）”；
- 使用 'c+' 模式（不存在则创建，存在则打开）而非 'r+'，因后者在某些系统上可能无法获得写锁；
- flock() 是建议性锁（advisory），依赖所有参与者主动调用，不能阻止未加锁的程序修改文件；
- 锁作用于整个文件，不是某段内容；若需细粒度控制（如多配置项独立更新），应考虑数据库；
- 生产环境建议增加错误日志、JSON 编码校验（json_last_error()）及备份机制（如写入前复制原文件）。
? 更健壮的替代方案：迁移到数据库
对于频繁读写、多用户协作的配置场景，文件存储天然不适合并发控制。推荐使用轻量数据库（如 SQLite、MySQL 或 PostgreSQL）：
CREATE TABLE app_config ( key VARCHAR(100) PRIMARY KEY, value TEXT NOT NULL, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );
借助数据库事务与行级锁（如 SELECT ... FOR UPDATE），可彻底规避竞态：
// PDO 示例（自动事务 + 行锁）
$pdo->beginTransaction();
$stmt = $pdo->prepare("SELECT value FROM app_config WHERE key = ? FOR UPDATE");
$stmt->execute(['theme']);
$oldValue = $stmt->fetchColumn();
$newValue = json_encode(array_merge(json_decode($oldValue, true), $updates));
$pdo->prepare("UPDATE app_config SET value = ?, updated_at = NOW() WHERE key = ?")
->execute([$newValue, 'theme']);
$pdo->commit();数据库不仅提供 ACID 保障，还支持版本控制、审计日志、权限管理等企业级能力。
✅ 总结
- ❌ 不加锁的“读-改-写”文件操作在并发下必然存在覆盖风险；
- ✅ flock() 是 PHP 中解决该问题最直接、低侵入的方式，适用于中小规模配置场景；
- ? 长远来看，将配置持久化交由数据库管理，是更可靠、可扩展、易维护的选择。
参考文档：PHP flock() 官方手册，SQLite 并发模型。
