raft实现核心难点在于状态机与网络交互的竞态控制，需严格加锁并持久化currentterm、votedfor、log；electiontimer必须每次重置为150–300ms随机超时，避免split vote；requestvote响应须校验term、votedfor及日志新旧；appendentries需正确初始化nextindex并依据conflictterm回退；所有log切片操作须前置边界检查防panic。
Go 实现 Raft 不是“套个库就能跑”，核心难点在状态机与网络交互的竞态控制——currentTerm、votedFor、log 这三处持久化字段一旦读写不加锁或未及时 persist()，选举就可能分裂，日志就可能回滚错乱。
为什么 electionTimer 必须用随机超时
固定超时会导致所有 Follower 同时转为 Candidate，引发反复投票失败（split vote）。Raft 论文明确要求超时区间为 150–300ms 随机值。实际编码中常见错误是：只在启动时随机一次，后续重置用固定值；或没在 runElectionTimer 的 for 循环里每次调用 randomTimeout()。
-
electionTimer.Reset(randomTimeout())必须放在锁内且每次触发后都重设 - 超时回调中若发现
state == Leader，直接 return，不能继续发起选举 - 收到任何带更高
Term的 RPC（如AppendEntries或RequestVoteResponse）时，必须立即降级为 Follower 并更新currentTerm
RequestVote 响应逻辑里的安全检查项
Follower 收到 RequestVote 请求后，不能无条件投票。必须逐条校验以下条件，任一不满足就返回 false：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 请求中的
Term → 拒绝，且带上自己的 <code>currentTerm -
votedFor != -1 && votedFor != candidateId→ 已投过票给别人，拒绝 - 候选人日志不如自己新：
candidateLogTerm ，或 <code>candidateLogTerm == lastLogTerm && candidateLogIndex → 拒绝（这是日志完整性保护的关键）
漏掉第三条，就会出现旧日志覆盖新日志，破坏 Raft 的 Safety。
Leader 发送 AppendEntries 时的 nextIndex 初始化陷阱
新当选 Leader 初始化 nextIndex 映射时，不能全设为 len(log)。因为 Follower 日志可能落后很多，直接从末尾开始同步会连续失败，触发大量 AppendEntriesResponse 中的 conflictIndex 回退逻辑，拖慢恢复速度。
- 正确做法：初始化为
len(log)，但首次失败后，根据响应里的conflictTerm向前查找该任期第一条日志索引，再设为nextIndex[peer] = conflictIndex - 务必检查响应中的
term字段：如果response.Term > currentTerm，说明对方已进入新任期，当前 Leader 应立即降级 -
matchIndex只能在收到成功响应（success == true）后才更新，且要取min(nextIndex[peer]-1, len(log)-1)，避免越界
最易被忽略的是：所有涉及 log 切片操作（比如 log[prevLogIndex:]）的地方，必须先做边界判断，否则 panic 会直接 kill goroutine，而 Raft 的定时器和 RPC 处理又高度依赖 goroutine 生存 —— 一个没 recover 的 panic 就等于节点静默下线。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
