setnx无法原子续期，因其仅支持首次设值、不支持更新ttl；业务超时会导致锁释放并发冲突，须用lua脚本校验value后pexpire，或采用redisson watchdog自动续期。
为什么 Redis 的 SETNX 不能直接用作分布式锁的自动续期基础
因为 SETNX 只能设置一次，无法在锁持有期间动态延长过期时间；一旦业务执行超时而锁自动释放，其他节点可能误入临界区，导致数据不一致。更麻烦的是，如果客户端崩溃或网络分区，锁长期滞留却无人清理，就形成死锁。
真正可用的方案必须满足：锁有唯一标识（防止误删）、支持原子性续期、具备超时兜底、且释放操作必须校验所有权。
- 推荐用
SET key value NX PX milliseconds初始化锁，其中value是客户端唯一 token（如 UUID），不是固定字符串 - 续期必须通过 Lua 脚本完成：先校验
key存在且value匹配，再EXPIRE，否则拒绝续期 - 不要依赖心跳 goroutine 频繁轮询续期——网络抖动可能导致重复续期或漏续，应结合业务执行周期做自适应重试
Go 里怎么安全实现带续期的 Redis 分布式锁（以 redigo 为例）
核心在于把“获取锁”“续期”“释放锁”三个动作封装成可组合、可中断的操作，而不是裸写 Do 命令。
示例关键逻辑：
// 续期脚本：只有值匹配才更新过期时间
const renewScript = `
if redis.call("GET", KEYS[1]) == ARGV[1] then
return redis.call("EXPIRE", KEYS[1], ARGV[2])
else
return 0
end`
// 调用示例
redisConn.Do("EVAL", renewScript, 1, "mylock", token, "30000")
- 续期间隔建议设为锁 TTL 的 1/3～1/2（比如锁 30s，每 10～15s 续一次），避免频繁请求也留出缓冲余量
- 使用
context.Context控制整个加锁+业务执行+续期流程的生命周期，超时后主动释放并 cancel 续期 goroutine - 务必在 defer 中调用释放逻辑，但释放前要再次 check token，防止释放了别人的锁
如何防止因 panic 或 goroutine 泄漏导致锁永远不释放
panic 不会自动触发 defer（除非 recover），而 goroutine 泄漏会让续期任务持续运行，最终撑爆连接数或耗尽 Redis 内存。
- 加锁后立即启动一个带 timeout 的续期 goroutine，并用
sync.Once确保只启一次 - 在业务函数外层用
defer+recover()捕获 panic，然后强制释放锁（仍需校验 token） - Redis 锁 key 必须设置明确的初始 TTL（如
PX 30000），绝不能依赖续期来“兜底”，这是防死锁的最后一道防线 - 上线前用
redis-cli --scan --pattern "mylock:*"定期抽检锁残留情况，观察是否出现长期未更新的 key
etcd 方案下怎么处理租约自动续期与上下文取消联动
etcd 的 lease 机制比 Redis 更适合自动续期场景，但容易忽略 lease ID 和 client 关联的生命周期管理。
- 创建 lease 时传入
clientv3.WithLeaseTTL(30)，拿到leaseID后立刻用KeepAlive启动续期流 -
KeepAlive返回的 channel 会在 lease 过期或 client 断连时关闭，必须监听该 channel 并退出续期 goroutine - 业务执行期间若收到 context cancel，需显式调用
client.Grant(ctx, ttl)新建 lease 并迁移 key，不能直接 close 原 lease - etcd 的
CompareAndSwap（即txn）才是真正的“加锁”动作，它和 lease 绑定，失败时要退避重试而非死等
最易被忽略的是：etcd lease 的续期是服务端行为，但客户端必须维持活跃连接；一旦网络闪断，KeepAlive channel 关闭后若没及时感知，锁就会静默失效。这比 Redis 多一层连接可靠性依赖。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
