context.WithTimeout无法保活分布式锁租约，因其仅控制单次操作超时，不自动续期；锁服务租约独立计时，需手动调用Refresh/KeepAlive，否则租约到期释放导致并发覆盖。
Go 的 context.WithTimeout 为什么不能直接保活分布式锁租约
因为 context.WithTimeout 只控制单次操作的截止时间，不负责续期。锁服务（如 Redis、etcd）的租约是独立计时的，客户端不主动刷新，租约到期就释放——哪怕你的 goroutine 还在跑。
常见错误现象："LOCK_EXPIRED" 或 "ERR NOAUTH"（Redis 中因锁 key 被删导致后续 DEL 失败），但业务逻辑仍以为持有锁在执行，引发并发覆盖。
- 使用场景：长时任务（如文件上传回调处理、批量账单结算）需持续持有锁，但又不能预估耗时
- 正确做法是启动一个独立 goroutine，在租约过期前定期调用
Refresh()或Extend()（取决于客户端 SDK 是否支持） - etcd 的
Lease.KeepAlive()是自动续期，但 Redis 的 Redlock 或单实例 SETNX + EXPIRE 没有内置保活，必须手动轮询GETSET或PEXPIRE - 性能影响：频繁续期会增加 Redis/etcd QPS；建议续期间隔设为租约 TTL 的 1/3～1/2，避免临界抖动
Redis 分布式锁在 Go 里怎么安全地「续期」而不丢锁
核心矛盾在于：续期操作本身可能失败（网络抖动、节点故障），而你又不能让续期 goroutine 和业务主流程共享锁状态变量——容易出现竞态或误判。
推荐用带版本号的原子操作，而不是单纯依赖 SET key value EX seconds NX 的原始方式。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 使用场景：基于 Redis 实现可续期锁，且要求高可用（容忍单点故障）
- 参数差异：
SET lock:order:123 "g1-abc456" EX 30 NX中的 value 必须是全局唯一标识（如uuid.NewString()+ goroutine ID），续期时用EVAL脚本比对 value 再PEXPIRE，防止误续他人锁 - 容易踩的坑：
redis.Client.SetEX()不带条件校验，直接覆盖 TTL，会导致 A 续了 B 的锁；务必用 Lua 脚本保证原子性 - 示例脚本：
if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("pexpire", KEYS[1], ARGV[2]) else return 0 end
etcd Lease KeepAlive 在 Go clientv3 里为什么有时会静默断连
clientv3.Lease.KeepAlive() 返回的 chan *clientv3.LeaseKeepAliveResponse 如果没人消费，底层 gRPC 流会被阻塞甚至关闭，继而导致租约实际过期——但你的代码可能还在用旧的 LeaseID 认为自己有锁。
这不是 bug，是流控机制的副作用：gRPC 客户端默认缓冲区有限，响应积压后会关闭流。
- 使用场景：用 etcd 实现强一致分布式锁，依赖
LeaseID关联 key - 必须启动一个 goroutine 持续读取
KeepAlive()返回的 channel，哪怕只做空循环：for range keepAliveChan {} - 更稳妥的做法是监听
ctx.Done()并检查*clientv3.LeaseKeepAliveResponse.ID是否为 0（表示流已断），此时应主动释放锁并报错 - 兼容性注意：v3.5+ client 支持
WithLease(leaseID)绑定 key，但老版本需手动Grant()后再Put()，顺序错就锁不住
并发冲突发生时，Go 程序该不该重试？重试几次才合理
不是所有冲突都适合重试。比如两个请求同时扣减库存，一个成功一个失败，失败方重试可能造成超卖；但如果是幂等写日志，重试就安全。
关键看操作是否具备「乐观锁语义」和「业务幂等边界」。
- 使用场景：数据库更新、Redis 计数器增减、etcd key 覆盖写入
- 判断依据：先查后改的操作，必须带版本号（
cas）、修订号（mod_revision）或时间戳比对；纯SET/PUT无条件覆盖，重试等于放弃一致性 - 重试策略：最多 2～3 次，间隔用指数退避（
time.Sleep(time.Millisecond * time.Duration(math.Pow(2, float64(attempt))))），避免雪崩 - 容易被忽略的点：重试逻辑必须包裹在同一个
context下，否则新请求可能拿到新租约，跟旧锁状态错位
租约续期和冲突重试都不是黑盒操作，它们和你的业务超时、监控埋点、失败降级路径紧密耦合。少一层抽象，就多一分可控。
