TP6.0 直接用 setnx 会引发三大问题：锁无过期时间导致死锁、返回值无法区分失败与超时、delete 解锁不校验归属致误删；应改用 set 的 NX+PX 原子操作，并配合唯一锁值与 Lua 脚本解锁。
TP6.0 中直接用 setnx 会出什么问题？
TP6.0 自带的 Cache::handler() 默认不支持原子性加锁，直接调用 setnx 命令（比如 $cache->setnx('lock:order', 'client1', 30)）看似可行，但实际会掉进三个坑：
-
setnx只设值，不设过期时间 → 客户端崩溃后锁永远不释放 - TP6 的
setnx方法返回布尔值，但没透出 Redis 原生命令的完整响应 → 无法判断是失败还是网络超时 - 解锁时若用
$cache->delete('lock:order')，任何客户端都能删 → A 拿到锁超时释放后，B 正在执行，A 的 unlock 会误删 B 的锁
TP6.0 推荐用 set 命令替代 setnx 实现原子加锁
TP6.0 的 Cache 类支持传入 Redis 原生参数，关键是要用 set 命令的 NX + PX 组合，而不是拼两个命令：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 正确写法：
$cache->set('lock:order', 'client1', ['nx' => true, 'px' => 30000]) - 返回值是
'OK'或false，不是布尔值 → 必须严格比对=== 'OK' - 注意：TP6.0.24+ 才完全支持
px参数；低版本需手动调用Cache::handler()->set(...)走原生连接 - 锁值必须唯一（推荐用
md5(uniqid().getmypid())），不能写死字符串，否则解锁校验失效
RedLock 在 TP6.0 里不是“开箱即用”，得自己搭骨架
TP6.0 没内置 RedLock，所谓“用 RedLock”其实是自己连多个 Redis 实例、做多数派投票。容易忽略的关键点：
- 不是简单连 5 个节点就行：必须确保至少 3 个独立 Redis 实例（不能是主从，得是不同物理机或容器）
- 每个实例加锁要单独计时 —— 用
microtime(true)记开始时间，每个set调用耗时超过总超时时间的 1/3 就放弃该节点 - 成功条件是：获得锁的节点数 > N/2（N 是总节点数），且剩余有效时间 > 业务执行预估耗时
- TP6 的
Cache不支持跨实例事务，得用new \Redis()手动建多个连接，别试图复用同一个Cache实例
解锁必须用 Lua 脚本，TP6.0 的 delete 不能信
无论用 setnx 还是 set 加锁，解锁都得靠 Lua 脚本保证“校验+删除”原子性。TP6.0 没封装这个逻辑，得自己写：
- 脚本内容固定：
if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1]) else return 0 end - 调用方式：
$redis->eval($script, 1, 'lock:order', 'client1')（$redis是原生连接） - 千万别用
$cache->delete()或Cache::pull()→ 它们不校验锁归属 - 如果用了 RedLock，解锁要遍历所有成功加锁的节点分别执行该脚本，失败节点跳过即可
PX 时间设太短怕超时，设太长怕故障堆积。真要高可靠，得自己实现 watchdog 机制，或者直接上 Redisson（虽不在 TP 生态内，但兼容性没问题）。 
