不建议从零手写 Raft 核心逻辑用于生产，但用 Go 实现可调试的最小可行模块完全可行；关键在拆解心跳、选举、日志复制三部分验证，避免过早堆砌 RPC 与持久化。
直接说结论：不建议从零手写 Raft 核心逻辑用于生产，但用 Go 实现一个可调试、可观察的最小可行 Raft 模块完全可行——关键在于分清「协议边界」和「工程封装」，把心跳、选举、日志复制三件事拆开验证，而不是一上来就堆 RPC 和持久化。
raft.StartElection() 触发后为什么节点卡在 Candidate 状态？
这是最常卡住新手的第一关。根本原因不是代码没跑，而是网络通信或任期（Term）校验失败。
- 检查
sendRequestVote()是否真的发出了请求：用net/http或log.Printf打点，确认目标地址（如"localhost:8081"）可连通，且对方节点已启动并监听 -
Term必须严格递增：若两个节点同时超时并自增Term，但其中一个先发请求、另一个后发，后者会因收到更高Term的响应而立即退回到 Follower —— 这不是 bug，是 Raft 设计的“任期压制”机制 - 投票只投一次：
votedFor字段必须在本Term内只设一次；如果重复调用startElection()而没重置状态，会导致后续投票被拒绝
AppendEntries RPC 中 index 和 term 不匹配导致日志复制失败
Leader 发送 AppendEntries 时携带的 prevLogIndex 和 prevLogTerm 是 Follower 日志一致性的“锚点”。不匹配就拒绝，这是 Raft 保证日志安全的核心检查。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- Follower 收到请求后，必须先查本地
logs[prevLogIndex]是否存在，且其Term是否等于prevLogTerm；任一不满足就返回Success: false - Leader 收到失败响应后，不能重试原 index，而应递减
nextIndex并重发 —— 这个“回退重试”逻辑极易遗漏，导致日志永远不同步 - 初期可简化：让所有节点从空日志开始，
prevLogIndex初始为 0，prevLogTerm为 0，避免早期索引越界
goroutine + channel 组合在心跳中引发竞态或泄漏
心跳看似简单，但并发模型下极易出问题：goroutine 泄漏、重复启动、锁竞争。
- 心跳 goroutine 必须可取消：用
context.WithCancel包裹，每次角色切换（如 Leader → Follower）时显式调用cancel()，否则旧心跳还在发，新 Leader 又启一套 - 不要在
for range peers循环里直接起 goroutine 并捕获循环变量p—— 所有 goroutine 会共享最后一个p值；必须写成gofunc(p string) { ... }(p) - 心跳间隔建议设为 100~200ms，超时设为 200~400ms；太短易触发误选举，太长则故障恢复慢；这两个值必须在测试中实测调整，不能照搬论文
真正难的不是写对选举或日志，而是让多个节点在真实网络中稳定地“感知彼此状态”。比如 CommitIndex 更新必须原子，LastApplied 推进必须与状态机应用严格串行——这些细节不打日志、不加断点，几乎不可能靠读代码发现。
