必须用Lua脚本释放锁，因其能原子执行“GET校验value+DEL删除”两步；若用单独DEL或GET+DEL分步操作，高并发下易误删他人锁。
直接用 DEL 删除锁 key 一定会出问题——它不校验 ownership，只要锁过期或客户端崩溃，任何后续客户端都能删掉别人刚拿到的锁。
为什么必须用 Lua 脚本释放锁
释放操作本质是「先读 value，再比对，再删」三步。拆成 GET + DEL 两步走，在高并发下必然出现竞态：A 读到自己的 value，还没来得及 DEL，B 已经把锁续期或重抢了，A 还是会把 B 的锁干掉。
Lua 脚本在 Redis 中原子执行，中间不会被其他命令插入。脚本里那句 if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("DEL", KEYS[1]) else return 0 end 就是唯一安全路径。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 不能用
EXISTS替代GET：你得比对具体 value，不是只判断 key 是否存在 - 不能用
redis.pcall包裹DEL：除非你明确想吞掉错误；正常场景用redis.call更直接 - 如果 key 已过期被自动清除，
GET返回nil，和ARGV[1]比较结果为false，脚本返回0，这是预期行为，不是失败
Java（Jedis）中调用 EVALSHA 的实操要点
高频释放锁时，每次传完整 Lua 字符串既浪费带宽，又可能触发 Redis 的 maxmemory 淘汰策略（尤其脚本较大时）。必须预加载 + 复用 SHA。
- 首次启动时用
SCRIPT LOAD提交脚本，拿到 SHA1 值（如"a1b2c3..."），缓存到应用内存或配置中心 - 后续全部走
EVALSHA：EVALSHA a1b2c3 1 order:123 550e8400-e29b-41d4-a716-446655440000 - Redis 重启后 SHA 失效，需 fallback 到
EVAL；但不能默认每次都EVAL，否则失去预加载意义 - Jedis 默认在单 connection 上完成
eval调用，若用连接池，确认没跨 connection（JedisPool 默认满足） - 务必检查返回值是
Long类型的1，而不是只看是否抛异常——返回0表示“不是你的锁”，这属于业务正常流
value 设计与续期配合的关键细节
脚本安全的前提，是 ARGV[1] 真的是你加锁时塞进去的那个值。它不能是时间戳、线程 ID 或可预测字符串，必须是全局唯一、不可伪造的随机标识（如 UUID v4）。
- 加锁用
SET lock:key uuid NX PX 30000，不是SETNX+EXPIRE两步：后者不原子，可能 key 设置成功但过期没设上 - 续期（renew）不是锦上添花，而是刚需：业务执行时间不确定，TTL 必须设，但设短了易过期，设长了故障时不释放。所以得用独立看门狗线程定期
EXPIRE，且每次续期前仍要GET校验 value - 续期间隔建议为 TTL 的 1/3（如 TTL=30s，每 10s 续一次），留出网络延迟余量
- 客户端断连后，看门狗必须停；否则可能给别人的锁续命，变成“僵尸续期”
最容易被跳过的点是：脚本本身不解决可重入。如果你需要同 client 多次加锁，value 就得带计数（如 "uuid:2"），Lua 脚本也得改成解析、减一、为 0 才删——这会让逻辑变重、出错面变宽。多数情况，应该由业务层控制重入，而不是靠 Lua 把锁做成“带状态的复杂对象”。
