etcd v3的election api是最稳妥的选主路径，基于lease+cas实现自动续期与失效检测；consul需手动处理session心跳与kv竞态，易脑裂。
Leader选举必须依赖外部协调服务，Go标准库不提供内置方案
Go语言本身没有分布式锁或选主原语，sync.Mutex只在单机有效。etcd 和 consul 是最常用的两个外部协调后端，但它们的选主机制、API抽象和失败语义差异很大——直接套用任一文档示例，大概率在脑裂、假活或超时恢复时出问题。
etcd v3 的 election API 是目前最稳妥的选主路径
etcd 官方客户端 go.etcd.io/etcd/client/v3 提供了封装好的 election 子包，底层基于 Lease + CompareAndSwap（CAS）实现，自动处理会话续期、Leader失效检测和通知。比手撸 watch + put + delete 更可靠。
实操建议：
- 务必设置合理的
lease TTL（如 15s），太短易因 GC 或网络抖动误踢 Leader；太长则故障恢复慢 - Leader 节点需定期调用
Lease.KeepAlive，否则 lease 过期后自动退位，其他节点才能抢到 - 监听
Election.Observe获取新 Leader 信息，不要轮询Getkey —— 触发大量无效读 - 退出前显式调用
Election.Resign，避免残留 lease 导致下次启动被拒
示例关键片段：
立即学习“go语言免费学习笔记（深入）”；
cli, _ := clientv3.New(clientv3.Config{Endpoints: []string{"localhost:2379"}})
e := clientv3.NewElection(cli, "my-service/leader")
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
if err := e.Campaign(ctx, "node-001"); err != nil {
log.Fatal("failed to campaign:", err) // 非 nil 表示抢主失败（已有 Leader 或 etcd 不可用）
}
// 此时已是 Leader，可开始工作
Consul 的 session + kv 模式需手动处理竞态与心跳
consul 没有原生选主 API，主流做法是用 session 创建带 TTL 的锁，再通过 kv.Put 写入 Leader 路径。但它的 session 续期是异步的，且 kv.Put 不支持原子 compare-and-set（CAS），容易出现双主。
常见错误现象：
- 网络分区时，两个节点都以为自己是 Leader（脑裂）
- 节点 GC 停顿 > session TTL，session 自动销毁，但本地代码没感知，继续以 Leader 身份运行
- 多个节点并发
Put同一个 key，后写入者覆盖前写入者，无冲突检测
补救措施：
- 每次操作前先
session.Info检查 session 状态，失效则立即停止服务 - 在
kv.Put时设置cas=0（仅当 key 不存在时写入），并校验返回值是否为true - 用独立 goroutine 每 1/3 TTL 调用
session.Renew，失败时触发os.Exit(1)而非重试——避免“僵尸 Leader”
etcd 和 consul 在 Leader 失效检测上的延迟差异很实际
etcd lease 过期是强一致的：一旦 lease TTL 到期，所有 watch 立即收到事件，新 Leader 最快在 1 个 TTL 周期内选出（通常
这意味着：
- 对高可用要求严的系统（如支付网关），优先选
etcd - 若已用 consul 做服务发现，又不想引入新组件，至少把 session TTL 设为 ≤ 10s，并调小
serf-interval和session_ttl_min配置 - 无论哪种方案，业务层都得实现幂等性——因为网络延迟可能导致旧 Leader 的请求在新 Leader 启动后才到达
真正难的不是怎么抢到 Leader，而是怎么让所有节点对“谁是当前 Leader”达成一致，以及如何安全地交出控制权。这个一致性边界不在 Go 代码里，而在你选的协调服务的语义里。
