因为etcd原生锁存在超时失败、租约续期不及时、leader切换延迟等问题，且clientv3.concurrency.mutex不校验持有者身份，易被强行解锁；需用owner id绑定租约、原子cas判断、指数退避重试、独立goroutine续约并严格校验owner后删除。
为什么不用 etcd 原生锁而要自己封装
因为 etcd 的 CompareAndSwap（CAS）接口在 K8s 集群内直接调用容易失败：客户端超时、租约续期不及时、Leader 切换期间响应延迟，都会让锁状态不可信。原生 clientv3.Concurrency.Mutex 虽然封装了租约和前缀隔离，但它默认不校验持有者身份——别人能强行 Unlock 你的锁。
实操建议：
- 必须用带 owner ID 的租约绑定锁 key，例如
/locks/my-job-123/owner存入随机 UUID，解锁前先读该值比对 - 避免用
WithLease单独设租约，而是用clientv3.NewLease(client)显式管理，便于主动Revoke或延长 - 不要依赖
context.WithTimeout控制锁获取时间，应结合clientv3.OpPut的clientv3.WithIgnoreValue()和clientv3.WithPrevKV()手动轮询判断
TryLock 必须支持可中断 + 可重试
分布式环境下，网络抖动或 etcd 短暂不可达会导致阻塞型锁操作 hang 住 goroutine，进而拖垮整个控制器的 reconcile 循环。
常见错误现象：context.DeadlineExceeded 报错后锁 key 还留在 etcd 中，且租约未释放，下次尝试直接失败。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 每次
TryLock前生成唯一ownerID（如uuid.New().String()），写入时用clientv3.OpPut(key, ownerID, clientv3.WithIgnoreValue(), clientv3.WithLease(leaseID)) - 用
clientv3.Txn()做原子判断：如果 key 不存在或PrevKV.Value等于当前ownerID，才认为加锁成功 - 失败后 sleep 指数退避（
time.Second * 1 ），最多重试 5 次，超过则返回 false
锁 key 设计要防 namespace 冲突和 GC 漏洞
K8s 多租户场景下，不同 namespace 的同名 job 可能抢同一个锁；另外，无人清理的过期锁 key 会堆积，etcd 存储压力增大。
使用场景：一个 CronJob 在多个 namespace 并行运行，每个实例需独占处理一份共享文件目录。
实操建议：
- 锁 key 格式固定为
/locks/{namespace}/{name}/{resource}，比如/locks/default/file-import-worker/file:///data/inbox - 绝不使用全局前缀如
/locks/，否则跨 namespace 无法隔离 - 在 defer 中注册清理逻辑：用
runtime.SetFinalizer不可靠，应配合 controller-runtime 的enqueueAfter或独立 goroutine 定期扫描lease.TTL() == 0的 key 并删除
Golang 里怎么安全地做锁续约
etcd 租约默认 TTL 是死值，一旦创建就无法动态延长；但业务处理时间不确定，硬设长 TTL 会造成锁滞留，设短又容易误释放。
性能影响：频繁调用 Lease.KeepAlive 会增加 etcd 连接压力，尤其当锁数量 > 100 时明显。
实操建议：
- 启动一个单独 goroutine 负责续约，用
lease.KeepAliveOnce(ctx, leaseID)每 1/3 TTL 时间触发一次，失败则标记锁失效 - 不要在锁持有者 goroutine 里同步调用
KeepAlive，避免阻塞主逻辑 - 续约失败后立即执行
client.KV.Delete(ctx, key)清理，而不是等租约自然过期
最易被忽略的是 owner 校验时机：解锁前只查一次 key 值不够，得在 Delete 操作里用 WithPrevKV() + Txn() 确保删的是自己设的值——否则可能删掉别人刚抢到的锁。
