Raft在Go中能跑通，但Term不原子递增、VotedFor未严格单次赋值、心跳与日志复制未分离——三处错误将导致节点卡死或脑裂。
直接说结论：Raft 在 Go 中能跑通，但Term不递增、VotedFor未校验、心跳与日志复制不同步——这三处写错，节点必然卡死或脑裂，不是“逻辑没跑对”，而是根本无法进入正常状态机流转。
Go 中 Term 必须在每次选举前原子递增
很多初学者把 Term 当成普通字段，在 startElection() 里只写 r.Term++，却没加锁或原子操作。一旦多个 goroutine 并发触发选举（比如网络抖动导致多个 Follower 同时超时），Term 就会漏增或重复增，后续所有 RequestVote 和 AppendEntries 的 Term 比较都会失效。
实操建议：
- 用
atomic.AddInt32(&r.currentTerm, 1)替代裸增，currentTerm字段类型必须是int32 - 所有涉及
Term的判断（如if req.Term > r.currentTerm）都必须在读取后立即加锁或用atomic.LoadInt32 - 不要在
HeartbeatLoop里重置Term——它只随选举推进，不随心跳重置
VotedFor 字段必须严格单次赋值且带任期绑定
错误写法：r.VotedFor = candidateID 出现在任意 RPC 处理中；正确逻辑是：仅当 req.Term == r.currentTerm 且 r.VotedFor == "" 时才允许赋值，并立刻持久化（哪怕只是写进内存变量）。
立即学习“go语言免费学习笔记（深入）”；
常见错误现象：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 一个节点在 Term=3 投过票，但在 Term=4 收到旧 Term=3 的投票请求，仍错误返回
VoteGranted=true - 同一 Term 内被两个 Candidate 同时请求，
VotedFor被覆盖，导致双 Leader
实操建议：
- 赋值前必须检查
req.Term >= r.currentTerm，且仅当req.Term == r.currentTerm且r.VotedFor == ""才允许写入 - 一旦写入
VotedFor，该 Term 内不能再改——这不是“偏好”，是 Raft 安全性前提 - 测试时故意让两个节点同时发起选举，观察
VotedFor是否只被设一次
心跳和日志复制不能共用同一 RPC handler
新手常把心跳和日志追加合并成一个 AppendEntries 接口，但没区分“空日志”和“带日志”的语义。Follower 收到空日志（心跳）要刷新 LastSeen，收到带日志则还要校验 PrevLogIndex 和 PrevLogTerm。混在一起处理，极易漏判日志冲突。
使用场景差异：
- 心跳：Leader 每 100ms 发一次，
Entries为空，LeaderCommit更新即可 - 日志复制：仅当有新命令时触发，必须校验
PrevLogIndex是否匹配本地日志，不匹配要回退重试
性能影响：
- 心跳走轻量路径，避免序列化/反序列化整个日志数组
- 日志复制失败时，Follower 应返回
term和nextIndex建议值，Leader 需据此调整PrevLogIndex重试——这个逻辑若缺失，集群会永久卡在“日志不一致”状态
最易被忽略的点：Raft 不是“写完就提交”，而是“多数节点成功落盘 + Leader 自己更新 CommitIndex”才算数。很多人在 replicateLog() 里只等 goroutine 返回，却没做 CommitIndex 的安全推进（需满足 Log[i].Term == currentTerm 且已复制到多数节点）。这个判断一旦出错，状态机永远不执行命令。
