不建议从零手写Raft选举逻辑用于生产环境，但可用Go实现可观察、可调试的最小选举模块，关键在于隔离超时、投票、任期三要素；常见卡在Candidate状态的原因包括RequestVote未发出、Term冲突退选、同一term重复投票；AppendEntries心跳失败需检查prevLogIndex和prevLogTerm一致性，并回退nextIndex重试；心跳goroutine须可取消且避免循环变量捕获，间隔与超时需实测调整。
不建议从零手写 Raft 选举逻辑用于生产环境，但用 Go 实现一个可观察、可单步调试的最小选举模块完全可行——关键在隔离超时、投票、任期三要素，而非一上来就拼 RPC 和状态机。
raft.StartElection() 卡在 Candidate 状态怎么办
这不是代码没跑，而是网络或 Term 校验失败。最常见原因有三个：
- sendRequestVote() 根本没发出去：用
log.Printf打点确认目标地址（如"localhost:8081"）是否可连通，且对方节点已启动并监听 - Term 冲突导致退选：两个节点同时超时自增
currentTerm，先发请求者获胜，后发者收到更高term响应后立即退回到Follower—— 这是 Raft 的“任期压制”，不是 bug - votedFor 被重复设置：同一
term内只能投一次票；若多次调用startElection()但未重置状态，后续请求会被拒绝
AppendEntries 心跳失败导致反复选举
Leader 发心跳时携带的 prevLogIndex 和 prevLogTerm 是 Follower 日志一致性的锚点，不匹配就拒绝，这是安全机制，不是通信故障。
- 检查
logs[prevLogIndex]是否存在，且其term是否等于prevLogTerm；任一不满足就返回Success: false - Leader 收到失败响应后，必须递减
nextIndex并重发，不能重试原 index —— 这个“回退重试”逻辑极易遗漏 - 初期可简化：所有节点从空日志开始，
prevLogIndex初始设为0，prevLogTerm设为0，避免索引越界
goroutine 心跳泄漏与竞态
心跳看似简单，但在并发模型下极易出问题：goroutine 泄漏、重复启动、锁竞争。
立即学习“go语言免费学习笔记（深入）”；
- 心跳 goroutine 必须可取消：用
context.WithCancel包裹，每次角色切换（如Leader → Follower）时显式调用cancel()，否则旧心跳还在发 - 不要在
for range peers循环里直接起 goroutine 并捕获循环变量p—— 所有 goroutine 会共享最后一个p值；必须写成go func(p string) { ... }(p) - 心跳间隔建议设为
100~200ms，超时设为200~400ms；太短易误触发选举，太长则恢复慢；这两个值必须实测调整，不能照搬论文
真正难的不是写对选举或日志，而是让多个节点在真实网络条件下稳定同步任期和投票状态——哪怕只差一个 mu.RLock() 或一处 select {} 漏写，都可能让整个集群卡在 Candidate 状态不动。
