raft选主逻辑极易因竞态、超时设计或状态误判导致脑裂，需重点调试runelectiontimer、startelection和requestvote；超时必须随机（如150–300ms）且每次重置重新生成，定时器收到心跳后重置，状态检查需加锁，requestvote响应须严格校验term、投票状态和日志新鲜度，投票计数须用atomic操作，成为candidate后须原子递增term、设置并持久化votedfor。
选主逻辑不是“写完就能跑通”的功能，而是整个Raft实现中最容易因竞态、超时设计或状态误判直接导致脑裂的环节。你不需要先搭完整集群，但必须在 runElectionTimer、startElection 和 RequestVote 三个函数上卡死调试——绝大多数 Raft 实现失败都发生在这里。
如何正确触发选举：超时机制必须带随机性
硬编码固定超时（比如统一设为 200ms）会导致所有 Follower 同时转为 Candidate，引发分裂投票。Raft 要求每个节点的 electionTimeout 是一个随机区间（常见为 150–300ms），且每次重置都要重新生成。
-
randomTimeout()必须用rand.New(rand.NewSource(time.Now().UnixNano()))初始化独立 seed，不能复用全局 rand - 超时定时器必须在每次收到心跳后重置：
rf.electionTimer.Reset(randomTimeout()) - 状态检查必须加锁：仅当
rf.state == Follower且未收到心跳才允许触发选举
RequestVote RPC 的关键校验点
这个 RPC 不是“发出去就完事”，它的响应逻辑决定了谁能真正成为 Leader。Follower 收到请求后，必须严格按论文 Figure 2 检查三项：
- 请求中的
term是否大于本地currentTerm；若小于，直接拒绝并返回当前 term - 若已投过票（
votedFor != "" && votedFor != candidateId），且仍在同一任期，拒绝投票 - 候选人日志不能比自己旧：比较
candidateLogTerm和lastLogTerm，相等时再比lastLogIndex
漏掉任意一条，都可能让落后节点当选，后续日志复制必然失败。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
投票计数为什么必须用原子操作
多个 goroutine 并发处理不同节点的 RequestVote 响应，votes 变量天然存在竞态。直接用 votes++ 会导致计数丢失，少数节点永远凑不够多数票。
- 声明时用
var votes int32，而非int - 递增必须用
atomic.AddInt32(&votes, 1) - 判断条件写成
atomic.LoadInt32(&votes) > int32(len(rf.peers)/2)，避免读取中间态
状态切换的隐藏陷阱：Term 递增与 self-vote
成为 Candidate 后，必须立刻做两件事：递增 currentTerm、将 votedFor 设为自己 ID，并持久化。缺一不可。
- Term 递增必须在锁内完成，且要同步更新
votedFor—— 否则可能被其他 goroutine 读到旧 term 和空votedFor -
votedFor一旦设置就不能再改（本任期），否则违反“最多一票”约束 - 务必调用
rf.persist()，否则崩溃重启后 term 回退，可能重复投票或拒绝合法 Leader
真正的难点不在代码行数，而在于每个状态转换点都要同时满足 term 一致性、投票唯一性、日志新鲜度三个维度的约束——少盯住一个，集群就停摆。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
