不能直接用EXPIRE续期分布式锁，因为会破坏互斥性：若原持有者因GC或网络延迟续期时锁已被其他客户端获取，EXPIRE将误续他人锁；必须通过Lua脚本原子校验value一致性后再PEXPIRE。
为什么不能直接用 EXPIRE 续期分布式锁
Redis 分布式锁的核心是「持有者唯一性 + 过期自动释放」，续期本质是延长锁的 TTL。但直接对锁 key 执行 EXPIRE 有严重风险：如果客户端 A 拿到锁后被 GC 停顿或网络延迟，此时锁已被其他客户端 B 重入（比如因超时被释放后抢到），A 再调用 EXPIRE 就会误续 B 的锁 —— 完全破坏互斥性。
必须保证「只有锁的原始持有者才能续期」，且整个判断+更新过程原子执行。Lua 脚本是 Redis 唯一能提供服务端原子性的机制。
EVAL 脚本如何安全续期：检查 value 再 PEXPIRE
锁的 value 必须是全局唯一标识（如 UUID 或 clientID:threadID），续期脚本需先比对当前 key 的 value 是否匹配，再更新过期时间。以下是最小可行脚本：
if redis.call("GET", KEYS[1]) == ARGV[1] then
return redis.call("PEXPIRE", KEYS[1], ARGV[2])
else
return 0
end
调用方式（以 redis-cli 为例）：
redis-cli --eval /path/to/extend.lua my:lock , "8f4a...b3e" 30000
-
KEYS[1]是锁 key（如my:lock） -
ARGV[1]是当前客户端持有的唯一 value（必须和加锁时一致） -
ARGV[2]是新 TTL，单位毫秒（如30000表示 30 秒） - 返回
1表示续期成功，0表示 value 不匹配（锁已丢失或被覆盖）
加锁与续期的 value 必须严格一致，且不能依赖时间戳
很多实现用 SET key uuid NX PX 30000 加锁，但续期时若用时间戳拼接 value（如 uuid:timestamp），会导致每次续期 value 都变，脚本比对必然失败。正确做法是：
- 加锁时 value 固定为客户端身份标识，不带任何动态字段
- 续期脚本只校验该固定 value，不关心锁已存在多久
- 避免在 value 中嵌入过期时间、线程名等易变信息
- 如果需要追踪锁生命周期，应额外用另一个 key 存储元数据，而非污染锁 value
续期失败后必须立即放弃，不可重试或 sleep 后再续
脚本返回 0 只有一个含义：当前客户端已失去锁所有权。此时继续尝试续期、或等待后重试，只会掩盖问题，导致业务逻辑在无锁状态下运行。正确响应是：
- 立刻中断当前临界区操作（如回滚事务、清理临时状态）
- 记录告警（如 log “lock extend failed, lock lost”）
- 按业务规则决定是否重试整个操作流程（注意：不是重试续期）
续期本身是守护行为，应在独立线程/协程中定时执行（如每 10 秒续一次），但每次调用都必须基于「当前仍持锁」的前提 —— 这个前提只能靠 Lua 脚本原子验证，别无他法。
