etcd分布式锁不能直接用Put+Delete模拟，因裸Put无自动过期、裸Delete无法校验所有权；必须用Lease绑定TTL，并通过CAS（PrevKV+Txn）确保加锁和释放的原子性与安全性。
etcd 分布式锁为什么不能直接用 Put + Delete 模拟
因为 etcd 的租约（lease）和键值原子性是锁安全的唯一基础，裸 Put 没有超时自动释放能力，节点崩溃后锁永远卡死；裸 Delete 无法判断“谁删的”，容易出现 A 删了 B 的锁、B 还以为自己持有锁的竞态。
正确做法必须绑定 LeaseGrant 创建带 TTL 的 lease，再用 Put 的 LeaseID 和 PrevKV 选项实现「仅当 key 不存在时写入」——这靠的是 etcd 的 Compare-and-Swap（CAS）语义。
-
Put必须传leaseID，否则锁不会自动过期 - 加锁要检查
resp.PrevKv == nil，而不是只看err == nil - 不要用
Get判断 key 是否存在再Put：中间窗口期会导致两个客户端同时认为“没人占着”
选主（leader election）用 Session 还是手动续租
clientv3.Session 封装了 lease 自动续期和失效监听，对选主场景更稳；但它的底层仍是定期调用 LeaseKeepAlive，一旦网络抖动或 GC 停顿导致续租延迟超过 TTL，session 就会过期，触发误切换。
生产环境建议用 Session，但必须配合短 TTL（如 5s）+ 高频心跳（续租间隔 ≤ TTL/3），并监听 Session.Done() 做降级处理。
立即学习“go语言免费学习笔记（深入）”；
- TTL 设为 3–10 秒之间，太短增加 etcd 压力，太长故障恢复慢
- 不要依赖
Session.Orphan()自动清理：它只在 client 正常关闭时生效，崩溃不触发 - 选主成功后，需立即用
Watch监听该 key 的 delete 事件，而非轮询
分布式锁的释放为什么必须用 CompareAndDelete
释放锁不是简单 Delete，因为可能被其他节点抢先抢到了锁，此时删掉的是别人的锁。必须确认「当前 value 等于自己当初设的 value」才能删——etcd 不支持原生 value 比较删除，得用 Txn 实现 CAS 删除。
典型错误是把锁 value 设成固定字符串（如 "locked"），这样所有客户端 value 相同，根本没法区分 ownership。
- 加锁时 value 必须唯一，推荐用随机
uuid或os.Getpid() + nanotime - 释放逻辑必须走
Txn().If(...).Then(...)，条件是cmp.Value("expected_value") == true - 不要在 defer 中无条件
Delete：panic 后没执行到 defer，或者 panic 恢复后又执行了一次
etcd v3.5+ 的 Lock API 能直接用吗
能，clientv3.NewLocker 提供了封装好的 Lock/Unlock，底层就是基于 lease + txn + watch，省去手写 CAS 的麻烦。但它默认使用全局 lease（所有锁共享一个 lease ID），一旦 lease 过期，所有锁同时失效——这不是 bug，是设计取舍。
如果你的应用里多个锁生命周期不同（比如一个服务既做定时任务调度又管配置热更新），混用 NewLocker 可能导致非预期的锁批量丢失。
- 单服务单用途场景（如纯选主），直接用
NewLocker安全省心 - 多锁共存且 TTL 需求不一致时，宁可手写带独立 lease 的锁逻辑
- 注意
NewLocker的Lock方法会阻塞直到抢到锁，超时不抛错而是返回 context cancel error，得自己判
