etcd 的 mutex 锁依赖 session lease 和 watch 机制，并非加锁即生效；需设合理 ttl、绑定独立 session、带业务前缀命名 key、配合上下文超时与幂等校验，防止脑裂和锁漂移。
etcd 的 Lock 接口不是“加锁即生效”，它依赖 session lease 和 watch 机制
Go 官方 etcd client（go.etcd.io/etcd/client/v3）里没有传统意义上的阻塞式 Lock() 函数，它的 clientv3.Concurrency.NewSession + clientv3.Concurrency.NewMutex 组合，本质是「租约竞争 + 前缀监听」。一旦 session 过期（比如网络抖动、GC 延迟导致心跳失败），锁会自动释放——这不是 bug，是设计前提。
- 不要在长耗时操作中裸用
Mutex.Lock()，必须配context.WithTimeout控制持有时间 - 每次成功加锁后，要主动调用
Mutex.Unlock()，否则依赖 lease 自动过期，可能引发锁漂移 - 多个服务实例同时争抢同一把锁时，etcd 不保证 FIFO，只保证「最终只有一个 winner」，顺序由 etcd leader 写入日志的先后决定
用 clientv3.Concurrency.NewMutex 时，key 命名必须带业务上下文前缀
etcd 的 mutex 实现靠的是在指定 key 下创建带序号的临时节点（如 /lock/order-service/00000000000000000001），如果所有服务都用同一个固定 key（比如硬编码 /lock），不同微服务会互相干扰，甚至出现 A 服务释放了 B 服务的锁。
- 推荐格式：
/lock/{service-name}/{resource-id}，例如订单服务锁某订单：/lock/order-svc/order_123456 - 避免使用纯数字或 UUID 作为顶层 key，etcd 的 lexicographic 排序对前导零敏感，
/lock/10会排在/lock/2后面 - 不要复用 session：每个 mutex 应绑定独立
clientv3.Concurrency.Session，混用会导致 lease 心跳冲突和意外释放
Mutex.Lock() 返回后，不代表业务逻辑安全执行——还要防「脑裂重入」
网络分区时，A 节点认为自己持锁成功并开始处理，B 节点因无法连 etcd 而误判锁已释放，也拿到了锁。等网络恢复，两个节点同时操作同一资源，分布式锁失效。
- 必须在业务逻辑内加入幂等校验，比如基于数据库 version 字段或 Redis
SETNX二次确认 - 锁的 lease TTL 建议设为 10–15 秒，太短（如 3 秒）易因 GC 或调度抖动误释放；太长（如 60 秒）故障恢复慢
- 加锁前先检查资源当前状态是否允许操作（例如订单是否已是「已支付」），不能只依赖锁存在与否
别直接用 clientv3.KV.Put 模拟锁，etcd v3 的 CompareAndSwap（CAS）语义不等于分布式锁
有人试图用 clientv3.OpPut 配合 clientv3.OpIf 实现自定义锁，但 etcd 的 CAS 是单次原子操作，无法解决「加锁 → 执行 → 解锁」整个流程的原子性。中间任意一步失败，锁就卡死。
立即学习“go语言免费学习笔记（深入）”；
-
clientv3.Concurrency.Mutex内部用了PUT+GET+WATCH多步协同，封装了 lease 续期和异常清理逻辑 - 手动实现容易漏掉 watch channel 关闭、context cancel 传播、lease revoke 清理等细节，线上出问题很难定位
- 如果你需要跨 etcd 集群或混合存储（比如部分锁走 Redis），应抽象出
Locker接口，而不是在业务里散落各种Put调用
真正麻烦的从来不是怎么拿到锁，而是怎么确认「此刻我还能安全操作」——网络不可靠、lease 心跳有延迟、业务逻辑可能 panic，这些都会让锁的状态和实际执行脱节。留出足够的心跳 buffer，加上资源层的终态校验，比死磕 etcd API 更管用。
