raft选举超时时间不能写死，必须随机化（如[150ms,300ms]），每次启动和选举失败后重生成；requestvote响应需按term、日志新旧顺序校验；投票统计须过滤任期；心跳与选举定时器必须分离。
raft选举超时时间为什么不能写死
硬编码 electionTimeout 会导致集群在不同负载或网络延迟下频繁触发无效选举，比如设成 150ms，在高延迟节点上可能每秒都超时、反复自增任期、拒绝合法投票，最终卡在 Candidate 状态。Raft 要求超时时间是随机的（通常取 [150ms, 300ms] 均匀分布），每次启动和每次选举失败后都必须重新生成。
实操建议：
- 用
time.Now().UnixNano()或rand.New(rand.NewSource(time.Now().UnixNano()))初始化随机源，避免所有节点生成相同序列 - 在
becomeCandidate()入口处调用resetElectionTimer()，而不是在定时器 goroutine 里固定重置 - 超时后不直接发起 RequestVote，先检查自身状态是否仍是 Candidate——防止旧定时器在状态已变（如收到更高任期 AppendEntries）后误触发
RequestVote RPC 的 term 和 log index 校验顺序很关键
如果先更新本地 currentTerm 再校验对方日志，可能错误地给一个日志更旧但 term 更高的节点投赞成票，破坏“领导者必须包含所有已提交日志”这一安全属性。
正确顺序必须是：
- 收到
RequestVote后，先比对对方term：若小于本地currentTerm，直接返回{term: currentTerm, voteGranted: false} - 再比对日志：用
lastLogIndex和lastLogTerm判断对方日志是否至少和自己一样新；注意要先判lastLogTerm != localLastLogTerm，再比lastLogIndex，否则 term 不同却只看 index 会出错 - 只有两项都通过，才更新本地
currentTerm、votedFor，并返回voteGranted: true
常见错误现象：voteGranted: true 但后续发现对方日志明显落后，导致集群选出一个无法推进 commit 的伪 Leader。
投票统计逻辑必须带任期过滤
多个选举并发发生时（比如网络分区恢复后），一个节点可能在不同任期收到多个 RequestVoteResponse。如果简单计数“收到 3 个 true 就 win”，很可能把 T2 的票算进 T1 的选举中，造成脑裂。
实操要点：
- 每个 Candidate 维护独立的
votesReceivedmap，key 是peerID，value 是{term: int, granted: bool} - 收到响应时，先检查响应中的
term是否等于当前本地currentTerm；不等则丢弃（说明该响应对应的是过期选举） - 统计时只累加
granted == true && response.term == currentTerm的票数 - 一旦本地
currentTerm因收到更高 term 的 AppendEntries 而提升，必须清空当前所有投票记录
心跳与选举定时器不能共用一个 ticker
用单个 time.Ticker 模拟“随机超时+定期心跳”看似省事，但实际会让心跳节奏被选举逻辑干扰——比如刚重置超时时间后，下一个 tick 可能 50ms 后就到，导致 Leader 频繁发空 AppendEntries，浪费带宽；或者超时抖动过大，影响可用性。
必须分离：
- Leader 使用固定周期
heartbeatInterval（如 50ms）的time.Ticker发送 AppendEntries - Follower/Candidate 使用
time.AfterFunc或独立time.Timer管理选举超时，每次重置都timer.Stop(); timer.Reset(newDuration) - 切忌在同一个 goroutine 里混写
select { case —— 定时器精度丢失、goroutine 阻塞风险高
容易被忽略的是：Candidate 状态下，收到任何有效 RPC（包括自己发出去的 RequestVote 响应）都要重置选举定时器；而 Leader 收到任何 AppendEntries 都要重置自己的心跳定时器——这个“重置时机”比定时器本身更容易出错。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
