beego自身无选主能力，须用etcd实现；90%故障源于抢到leader后未续租、未监听observe退出信号或共用election实例致cas冲突和双主；campaign成功仅获初始key，须独立协程keepalive并select监听observe关闭以及时退场。
Beego 框架本身不内置选主能力，必须依赖外部协调服务；用 Etcd 实现多节点选主时，90% 的线上故障不是出在“抢不到 leader”，而是抢到后没续租、没监听退出信号、或多个 Beego 实例共用同一 concurrency.Election 对象导致 CAS 冲突——这会让 leader 切换频繁抖动，甚至出现双主。
Beego 启动时如何安全初始化 Election 实例
Beego 的 App.Run() 是阻塞调用，不能把选主逻辑塞进 main() 后直接启动 goroutine，否则可能在路由未就绪时就开始处理任务。必须确保：concurrency.Election 实例与 Beego 应用生命周期对齐，每个 Beego 进程独占一个 Election 实例，key 路径带唯一标识（如主机名或进程 PID）。
- 在
app.conf中配置 etcd endpoints 和 election key 前缀，例如etcd.endpoints = http://127.0.0.1:2379，election.key = /beego/leader/webapi - 在
models/init.go或自定义init()函数中初始化clientv3.New(...)，再传给concurrency.NewElection(...)，不要复用全局 client - key 必须带租约 ID，且写入时强制使用
cmp.Version(key) == 0条件，否则多个实例同时启动会覆盖彼此，触发脑裂
为什么 Election.Campaign() 成功后仍要监听 Observe()
Election.Campaign() 只是一次性原子操作，它不保证后续 lease 持有状态。etcd 的 lease 默认 TTL 是 10 秒，而 Go 客户端从不自动续租——你必须自己起 goroutine 调用 Lease.KeepAlive()，并用 select 监听 Election.Observe() 返回的 channel。一旦该 channel 关闭或收到 nil，说明你已被踢出 leader 角色，必须立刻停止所有业务逻辑（比如关掉定时器、拒绝新 HTTP 请求、清空本地缓存）。
- 不要只做
for range obs := range election.Observe()，因为 channel 关闭后 range 会 panic；必须用select { case resp, ok := - 收到
resp.Header.Revision == 0或resp.KV == nil，即表示已失权，不可再调用Election.IsLeader()判断 - Beego 的
Controller中若需判断是否 leader，应读取本地原子变量（由 Observe goroutine 更新），而非反复调用IsLeader()—— 它只是缓存值，不反映真实状态
如何让 Beego 的 HTTP Server 配合 leader 状态动态启停
不能靠 “启动时选一次 leader 就一直跑”，必须支持运行时降级。常见做法是：在 Beego 的 Router 初始化之后、App.Run() 之前，启动一个独立 goroutine 执行选主循环，并用 sync.Once 控制 HTTP Server 的启动与关闭。
- 首次当选 leader 时，调用
beego.BeeApp.StartServer()（注意：Beego 2.x 中需用beego.RunWithMiddleWares()替代旧版Run()） - 失权时，调用
beego.BeeApp.StopServer()并等待 graceful shutdown 完成，再进入下一轮竞选 - 避免在
Observe()goroutine 中直接调用StopServer()—— 它会阻塞，导致后续通知无法接收；应发 signal 到另一个控制 goroutine 处理 - HTTP 路由中敏感接口（如配置热更、任务触发）应前置中间件检查本地 leader 标志，非 leader 节点返回
403 Forbidden或重定向到 leader 地址
真正难的不是“怎么当上 leader”，而是“怎么知道自己不再是 leader”。Etcd 不会等你轮询，它通过 Observe() 主动推送变更；而 Beego 的生命周期管理又和标准 Go server 不完全一致——漏掉 channel 关闭判断、把续租和监听混在一个 goroutine、或者让 controller 直接读 IsLeader()，都会让系统在故障时继续误服务。这些细节不写进日志，也不报错，只会在流量高峰时悄悄丢任务。
