Bully算法更适合Go初学者实现简单分布式选举，因其仅需节点ID比较和HTTP请求响应，无需Raft的任期、日志、持久化等复杂协议机制，能聚焦练习net/http、sync.WaitGroup、time.AfterFunc、json编解码等核心Go特性。
直接说结论：用 Go 实现“简单分布式选举”，首选 Bully 算法，而非 Raft；Raft 适合理解协议边界，Bully 才适合快速验证多节点协作逻辑。
为什么 Bully 比 Raft 更适合作为语言学习起点
刚学 Go 时想跑通“多个节点选 Leader”，最容易卡在 Raft 的 Term 校验、prevLogIndex 匹配、心跳 goroutine 泄漏这些细节上——它们不是语言问题，而是协议工程复杂度。Bully 没有任期、没有日志、不依赖持久化，只靠节点 ID 比较和 HTTP 请求响应就能跑起来。
你真正想练的，是 Go 的：net/http 客户端/服务端、sync.WaitGroup 控制并发、time.AfterFunc 模拟超时、json.Marshal 编解码——这些 Bully 全覆盖，Raft 却会把你拖进 RPC 重试、状态机应用、快照压缩等非语言范畴。
- Bully 节点只需暴露一个
/elect接口，收到请求就比 ID，响应带{"winner":"node-2"} - 发起方遍历 peers 列表发
http.Post，用context.WithTimeout控制单次请求不卡死 - 所有逻辑可写在单个
main.go里，无需拆raft.Node、raft.Storage等抽象层
用 net/http 实现 Bully 的三个关键点
别碰 gorilla/mux 或 gin，原生 net/http 足够清晰。重点不是框架，而是理解“谁发、谁收、谁赢”这个链条怎么串起来。
立即学习“go语言免费学习笔记（深入）”；
- 每个节点启动时注册两个 handler：
http.HandleFunc("/status", statusHandler)返回当前角色（Candidate/Leader），http.HandleFunc("/elect", electHandler)处理投票请求 -
electHandler中解析请求 body 得到发起者 ID，若自己 ID 更大，就向发起者发回http.StatusConflict+{"higher_id":"node-3"}，否则返回http.StatusOK - 发起方收到任一
200 OK就立即退出选举循环；收到所有409 Conflict才宣布自己胜出——这个“全失败才赢”的逻辑极易写反
常见错误：节点启动顺序和网络可见性
本地测试时，localhost:8001、localhost:8002 这种地址看似能通，实际常因端口被占、防火墙拦截或 http.Client 默认 timeout 太短（默认 30s）导致请求静默失败。
- 启动前先用
lsof -i :8001（macOS/Linux）或netstat -ano | findstr :8001（Windows）确认端口空闲 - 所有节点必须在同一个局域网内，或全部绑定
0.0.0.0:8001而非127.0.0.1:8001，否则互相 ping 不通 -
http.Client必须显式设置Timeout: 2 * time.Second，否则一个节点挂掉会导致整个选举阻塞 - 用
curl -v http://localhost:8001/elect -d '{"candidate":"node-1"}'手动触发，比等超时更可控
下一步该关注什么
当三节点 Bully 能稳定选出 Leader 后，别急着加日志复制——先改两件事：一是把节点列表从硬编码改成通过命令行参数传入（flag.StringSlice），二是让 Leader 主动向其他节点发 /heartbeat，Follower 收不到就重新发起选举。这两步做完，你就已经摸到了 Raft 心跳与角色切换的门把手，而不是被它绊倒。
