用 redis.client.set 实现分布式锁必须使用 set key value ex 30 nx 原子命令，go 中需传 redis.setnx 模式与过期时间；value 必须唯一（如 uuid），释放锁须用 lua 脚本校验 value 后删除；续期间隔应远小于 ttl 并设超时；etcd 方案需确保 leaseid 与 keepalive 生命周期严格对齐。
用 redis.Client.Set 实现分布式锁为什么总失效
因为 Set 默认不带原子性校验，SET key value EX 30 NX 才是正确姿势——Go 的 redis.Client.Set 方法里，NX（仅当 key 不存在时设置）和 EX（过期时间秒级）必须同时传入，否则可能多个实例同时写入成功。
常见错误现象：redis: nil 返回后仍继续执行业务逻辑；或锁未释放导致后续所有请求阻塞。
-
Set(ctx, key, value, time.Second*30)缺少NX，等价于普通写入，完全不是锁 - 正确写法是
Set(ctx, key, value, &redis.Options{Expire: time.Second * 30, Mode: redis.SetNX})（Mode: redis.SetNX是 v9+ 写法；v8 用SetNX独立方法） - value 必须唯一（推荐用随机 UUID），否则释放锁时无法判断是否自己加的锁
释放锁时用 DEL 直接删 key 会误删别人持有的锁
因为锁的 value 是持有者身份标识，直接 DEL 不校验 value，A 实例的锁超时自动释放后，B 实例还没执行完，C 实例拿到锁并开始执行，此时 A 恢复过来一通 DEL，就把 C 的锁干掉了。
必须用 Lua 脚本保证“判断 value + 删除”原子执行：
立即学习“go语言免费学习笔记（深入）”；
if redis.call("GET", KEYS[1]) == ARGV[1] then
return redis.call("DEL", KEYS[1])
else
return 0
endGo 中调用方式：
- 用
redis.Eval或redis.EvalSha执行上述脚本 - KEYS[1] 传锁 key，ARGV[1] 传当前实例生成的唯一 value
- 返回值为
int64：1 表示删除成功，0 表示非本实例所持，不可删除
在 K8s 多 Pod 场景下，锁续期（renew）比超时时间还慢就必然丢锁
Pod 可能被调度、网络抖动、GC STW 延长，导致心跳续期延迟。如果锁 TTL 是 15 秒，但续期任务每 10 秒跑一次，某次卡到 12 秒才发请求，那剩下 3 秒内只要再卡一次，锁就过期了。
真实场景中，续期间隔必须远小于 TTL，且要预留 buffer：
- TTL 设为
30 * time.Second，续期间隔建议 ≤8 * time.Second - 续期本身也要设超时（如
ctx, _ := context.WithTimeout(context.Background(), 500*time.Millisecond)），避免阻塞主流程 - 不要依赖定时器硬间隔，改用 “上一次续期成功后立即计算下次时间”，防止 drift 累积
用 etcd 替代 Redis 做分布式锁时，LeaseID 和 KeepAlive 的生命周期必须对齐
etcd 的租约不是绑定到 key 上的，而是由客户端主动维持；一旦 KeepAlive channel 关闭或 client 断连，租约立刻失效，key 自动删除——这和 Redis 的被动过期完全不同。
容易踩的坑：
- 在一个 goroutine 里调用
c.KeepAlive，但没处理的 close 或 error，导致续期静默失败 - 把同一个
LeaseID复用在多个 key 上，一个 key 删除不影响其他，但租约一挂全崩 - 创建 lease 时没设足够长的 TTL（如
LeaseGrant(30)），又没及时LeaseRenew，比 Redis 更容易丢锁
复杂点在于：K8s 环境下 etcd 集群本身也有网络分区风险，lease 续期失败未必是应用问题，得结合 etcdserver: request timed out 日志交叉判断。
