线上稳定微服务集群应优先用client-go leaderelection包而非etcd concurrency.Election，因后者90%故障源于续租失败后未及时退场：Proclaim()仅获初始key，lease需显式KeepAlive()，过期后key被删但程序仍运行；必须监听Observe()通道接收退位信号，且不可复用同一Election对象。
别自己手撸 Raft 或 Bully，线上稳定跑的微服务集群，基本都用 client-go 的 leaderelection 包——它不依赖 etcd/consul 等外部中间件，纯走 Kubernetes API Server，且已规避网络分区、时钟漂移、lease 续租失败等绝大多数坑。
为什么不能直接用 etcd concurrency.Election 跑生产？
它能快速跑通 demo，但 90% 的线上故障切换失败，都源于 lease 续租失败后程序没退场：
-
Proclaim()成功只代表抢到初始 key，不代表能一直 hold 住；etcd lease 必须显式KeepAlive()，客户端不会自动续 - 网络抖动或 goroutine 阻塞导致续租失败 → lease 过期 → key 被删 → 但你的业务逻辑还在跑，形成“幽灵 leader”
-
Election.IsLeader()返回true可能是缓存旧状态，实际早已被踢出；必须监听Observe()通道才能收到 etcd 主动推送的退位信号 - 多个实例共用同一个
concurrency.Election对象，CAS 冲突率飙升，leader 切换像抽风
client-go leaderelection 怎么配才不出事？
核心三步：建锁、设参、启选举。关键参数不是随便填的：
- 锁类型必须选
LeasesResourceLock（K8s 1.14+ 默认），比ConfigMapsResourceLock更轻量，更新原子性强，TTL 由 server 强制保障 -
identity必须唯一且稳定：推荐用 Pod UID（os.Getenv("POD_UID")）或启动时生成的 UUID；用随机字符串会导致重启后旧 lease 残留，新实例抢不到锁 -
LeaseDuration≥ 15s，RenewDeadline设为 10s，RetryPeriod设为 2s —— 这组值经大规模集群验证，平衡了故障发现速度与 GC/网络抖动误判风险 -
OnStartedLeading回调里千万别同步执行耗时业务；必须起 goroutine，否则会卡住 lease 续期，触发主动让位
etcd 原生 election 用法里最容易漏的细节
如果硬要用 etcd v3 的 concurrency.Election，以下四点漏掉任意一个都会脑裂：
立即学习“go语言免费学习笔记（深入）”；
- 写 leader key 时必须带
LeaseID，且加cmp.Version("key") == 0条件 —— 否则后写入者直接覆盖前人，多个节点同时认为自己是 leader -
Observe()返回的chan *concurrency.ElectionResponse必须用select+case <-ch:+case <-ctx.Done():双重判断；channel 关闭或 nil 响应时，立刻停止消费队列、关闭定时器 - 续租必须单独起 goroutine，读
Lease.KeepAlive()返回的chan *clientv3.LeaseKeepAliveResponse；不消费这个 channel，context cancel 后续租会静默失效 - 绝不缓存
isLeader状态到全局变量；每次关键操作前，用Get(ctx, leaderKey)检查真实状态 —— 本地 bool 和 etcd 实际状态错位，不会报错，只会静默出错
真正难的不是抢到 leader，而是持续确认自己还是 leader；所有“以为自己是 leader”的时刻，都是故障的起点。
