Redis SETNX加锁常失效，因不支持自动过期，易致死锁；可靠方案需原子设置key、过期时间及唯一value标识，解锁须Lua脚本校验value再删除。
Redis SETNX 命令加锁为什么经常失效
因为 SETNX 只管“设值”，不管“过期”，一旦客户端崩溃或网络中断，锁就永远卡在 Redis 里，其他服务等死。这不是锁，是幽灵锁。
真正可用的方案必须同时满足：原子性设置 key + 过期时间 + 唯一标识（防止误删）。PHP 里最稳的做法是用 SET 命令的 EX 和 NX 选项，再带上 GET 不行，得用随机 value 标识持有者：
$lockKey = 'order:pay:12345';$lockValue = uniqid('', true); // 必须全局唯一，不能用时间戳或固定字符串$result = $redis->set($lockKey, $lockValue, ['nx', 'ex' => 30]); // 30秒自动过期
注意：nx 和 ex 要一起传，老版本 PHP Redis 扩展不支持数组参数，得拼成 ['NX', 'EX', 30]；PHP 8.0+ 的 Redis::set() 才认关联数组。
解锁时 DEL 直接删 key 会出大问题
DEL 是无脑删，如果 A 拿到锁但执行慢，超时自动释放了，B 拿到了新锁，这时 A 才去调 DEL，就把 B 的锁干掉了——典型的“越权解锁”。
立即学习“PHP免费学习笔记（深入）”；
解锁必须校验 value 是否匹配，且整个操作要原子。PHP 没有原生支持 Lua 脚本的便捷封装，所以得手写 EVAL：
if redis.call("GET", KEYS[1]) == ARGV[1] then
return redis.call("DEL", KEYS[1])
else
return 0
end
对应 PHP 调用：
$script = "if redis.call('GET', KEYS[1]) == ARGV[1] then return redis.call('DEL', KEYS[1]) else return 0 end";$redis->eval($script, [$lockKey], 1, $lockValue); // 第三个参数是 key 数量，别写错
漏掉 $lockValue 或把 1 写成 0，脚本就永远返回 0，锁删不掉。
PHP-FPM 多进程下用 file_get_contents + flock 不算分布式锁
有人用 flock() 锁本地文件，或者用 file_get_contents 读写一个 lock.txt，这只能拦住同一台机器上的多个 PHP 进程，跨服务器完全无效。Redis、etcd、ZooKeeper 才是真分布式场景的基础设施。
如果你的业务部署在多台机器，又没上 Redis，别硬凑——要么加 Redis，要么承认当前架构不支持强一致性锁，改用幂等设计或最终一致性补偿。
另外，pcntl_fork() 在 Web SAPI（如 FPM）里基本不可用，信号处理混乱，别试。
Redis 主从切换时锁可能重复获取
主节点写入锁成功，还没同步到从节点，主挂了，从升主，新主上没有这个 key，另一个客户端立刻 SET 成功——两个服务同时持锁。这是 Redis 单机模式天然缺陷。
严格场景必须用 Redlock 算法（5 个独立 Redis 实例，多数派写入才算成功），但 PHP 生态里靠谱实现极少，php-redlock 库已多年未维护，且 Redlock 本身在某些网络分区下仍有争议。
更现实的选择是：接受小概率冲突，用业务层兜底（比如支付订单加数据库唯一索引 + 插入前 SELECT 判断），而不是在锁上死磕。
锁不是银弹，它只是把并发问题从“执行中”挪到“获取时”。真正难的永远是业务逻辑怎么扛住重试和乱序。
