文件锁（flock）仅适用于单机、无集群且操作同一文件的场景，如日志追加、配置热更新、临时计数器写入，须用lock_ex，注意nfs/容器挂载下失效及多进程句柄隔离问题。
PHP高并发场景下，锁不是“选一个用就行”，而是要按资源类型、一致性要求和部署架构分层决策——文件锁管本地写入，Redis锁管跨服务互斥，数据库行锁管事务内强一致。
文件锁（flock）适合什么场景？
只在单机、无集群、且操作对象是**同一文件**时才真正安全。比如日志追加、配置文件热更新、临时计数器写入。
- 必须用
LOCK_EX（独占锁），LOCK_SH（共享锁）在写场景下完全无效 - 锁生命周期绑定
fopen句柄，fclose或脚本结束自动释放——别忘了flock($fp, LOCK_UN)显式释放，否则可能被其他进程阻塞超时 - 致命陷阱：
flock在 NFS 或某些容器挂载路径上不可靠，会静默失效；PHP-FPM 多进程下若文件句柄未正确隔离（如全局复用$fp），锁会失效 - 性能差：每次调用都触发系统调用，高并发下争抢严重，不建议用于每秒百次以上的关键路径
Redis分布式锁（Lock\Lock 库）怎么避免翻车？
这是 PHP 微服务/多实例部署下的主力选择，但默认配置极易出问题。
- 必须设置带自动过期的锁：
ttl参数不能省，否则 Redis 进程崩溃后锁永远不释放（死锁） - 不要用
SET key value EX 10 NX手写实现——缺乏原子性续期（lease renew）能力；推荐用Lock\Lock库并传入['ttl' => 3000, 'retry' => 100] - 锁 key 必须带业务上下文前缀，比如
lock:order:12345，避免不同订单互相覆盖 - 释放锁必须校验 value（随机 token），防止 A 加锁后超时，B 覆盖加锁，A 误删 B 的锁——
Lock库内部已做，但自研方案常漏掉这点
MySQL 行锁（SELECT ... FOR UPDATE）什么时候能信？
仅在事务中、且 WHERE 条件命中**唯一索引或主键**时才真正锁定单行。否则会升级为表锁或间隙锁，拖垮整个库。
立即学习“PHP免费学习笔记（深入）”；
- 必须开启事务：
$pdo->beginTransaction()，且最后commit()或rollback()，否则锁一直挂着 - WHERE 条件没走索引？查一下
EXPLAIN——如果显示type: ALL，那这把锁等于没锁，还堵住别人 - 别在事务里混用
SELECT ... FOR UPDATE和普通SELECT，后者可能读到旧快照（取决于隔离级别），导致逻辑错乱 - 超卖防护典型写法：
UPDATE storage SET stock = stock - 1 WHERE id = 1 AND stock > 0+ 检查affected_rows === 1，比锁更轻量、更可靠
真正难的不是“怎么加锁”，而是判断“要不要加锁”——很多所谓并发问题，其实是设计缺陷：库存扣减不该直连 DB 扣，该走 Redis 原子指令；订单生成不该等邮件发完才返回，该扔进队列。锁只是兜底手段，不是性能解药。
