raft节点卡在candidate状态的根本原因是网络通信失败或任期校验失败：sendrequestvote()未发出、目标节点不可达、term未严格递增导致被压制、votedfor重复设置被拒绝。
raft.StartElection() 卡在 Candidate 状态怎么查
这不是代码没跑，而是网络或任期校验失败。最常见的是 sendRequestVote() 根本没发出去，或者对方节点没监听、地址写错（比如写成 "127.0.0.1:8081" 但实际监听的是 "localhost:8081"）。
用 log.Printf("sending vote to %s", peer) 打点确认请求是否发出；再用 telnet localhost 8081 或 curl -v http://localhost:8081/health 验证目标端口可达。
Term 必须严格递增：两个节点同时超时自增 Term，若 A 先发请求、B 后发，B 收到 A 的更高 Term 响应后会立刻退回到 Follower —— 这是 Raft 正常压制行为，不是 bug。votedFor 字段必须在本 Term 内只设一次；重复调用 startElection() 而未重置状态（如清空 votedFor、重置选举计时器），会导致后续投票被拒绝。
AppendEntries 中 prevLogIndex/prevLogTerm 不匹配导致日志不同步
这是日志复制失败的主因，本质是 Follower 日志“锚点”校验失败。logs[prevLogIndex] 必须存在，且其 Term 必须等于 prevLogTerm；任一不满足，Follower 就返回 Success: false。
Leader 收到失败响应后，不能重试原 nextIndex，而必须递减 nextIndex 并重发 —— 这个“回退重试”逻辑极易遗漏，直接导致日志永远卡住。
初期调试建议：所有节点从空日志启动，设 prevLogIndex = 0、prevLogTerm = 0，绕过索引越界问题；等基础流程跑通再放开真实日志索引。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
心跳 goroutine 泄漏或竞态怎么避免
心跳看似简单，但并发下极易出问题：
每个心跳 goroutine 必须绑定可取消的 context.Context，角色切换（如 Leader → Follower）时显式调用 cancel()；否则旧心跳还在发，新 Leader 又启一套，造成重复 RPC 和 Term 冲突。
不要在 for range peers 循环里直接起 goroutine 并捕获循环变量 p——所有 goroutine 共享最后一个 p 值；必须写成 go func(p string) { ... }(p)。
心跳间隔建议设为 150ms，选举超时设为 300ms；太短易误触发选举，太长则故障恢复慢；这两个值必须在本地多节点实测调整，不能照搬论文或示例。
要不要自己手写 Raft 核心逻辑
生产环境不建议。Raft 的边界很清晰：心跳、选举、日志复制三件事拆开验证可行，但一旦叠加 RPC 序列化、持久化、快照、网络分区恢复，复杂度指数上升。
更现实的选择是基于 hashicorp/raft 封装：它已通过 Consul、InfluxDB 等项目长期验证，暴露了 Apply()、Snapshot()、Transport 等可插拔接口，你只需专注业务状态机（比如把日志条目映射为缓存 SET 操作）。
自己实现时最容易被忽略的，是错误路径的完整性 —— 比如 AppendEntries 失败后不回退 nextIndex，或 RequestVote 返回 term > currentTerm 时不立即降级，这些细节不覆盖，集群就无法收敛。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
