不建议从零手写 Raft 核心逻辑用于生产，但用 Go 实现可调试的最小可行模块完全可行——需拆解心跳、选举、日志复制三部分验证；常见卡在 Candidate 状态主因是网络不通或 Term 校验失败，如重复投票、prevLogIndex/Term 不匹配、心跳 goroutine 泄漏等。
不建议从零手写 Raft 核心逻辑用于生产，但用 Go 实现一个可调试、可观察的最小可行模块完全可行——关键在于分清「协议边界」和「工程封装」，把心跳、选举、日志复制三件事拆开验证，而不是一上来就堆 RPC 和持久化。
raft.StartElection() 触发后为什么节点卡在 Candidate 状态
这是最常卡住新手的第一关。根本原因不是代码没跑，而是网络通信或任期（Term）校验失败。
- 检查
sendRequestVote()是否真的发出了请求：用log.Printf打点，确认目标地址（如"localhost:8081"）可连通，且对方节点已启动并监听 - Term 必须严格递增：若两个节点同时超时并自增
currentTerm，但其中一个先发请求、另一个后发，后者会因收到更高 Term 的响应而立即退回到Follower—— 这不是 bug，是 Raft 设计的“任期压制”机制 - 投票只投一次：
votedFor字段必须在本 Term 内只设一次；如果重复调用startElection()而没重置状态，会导致后续投票被拒绝
AppendEntries RPC 中 index 和 term 不匹配导致日志复制失败
Leader 发送 AppendEntries 时携带的 prevLogIndex 和 prevLogTerm 是 Follower 日志一致性的“锚点”。不匹配就拒绝，这是 Raft 保证日志安全的核心检查。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
logs[prevLogIndex]是否存在，且其Term是否等于prevLogTerm；任一不满足就返回Success: false - Leader 收到失败响应后，不能重试原
index，而应递减nextIndex并重发 —— 这个“回退重试”逻辑极易遗漏，导致日志永远不同步 - 初期可简化：让所有节点从空日志开始，
prevLogIndex初始为 0，prevLogTerm为 0，避免早期索引越界
goroutine + channel 在心跳中引发竞态或泄漏
心跳看似简单，但并发模型下极易出问题：goroutine 泄漏、重复启动、锁竞争。
立即学习“go语言免费学习笔记（深入）”；
- 心跳 goroutine 必须可取消：用
context.WithCancel包裹，每次角色切换（如Leader → Follower）时显式调用cancel()，否则旧心跳还在发，新 Leader 又启一套 - 不要在
for range peers循环里直接起 goroutine 并捕获循环变量p—— 所有 goroutine 会共享最后一个p值；必须写成go func(p string) { ... }(p) - 心跳间隔建议设为 100~200ms，超时设为 200~400ms；太短易触发误选举，太长则故障恢复慢；这两个值必须在测试中实测调整，不能照搬论文
真正难的不是写对选举或日志，而是让多个节点在真实网络条件下稳定交换状态——比如 net.Conn 的读写超时设置、RPC 消息序列化是否带 Term 字段、Follower 收到旧 Term 请求时是否立即响应 Term: currentTerm 而非静默丢弃。这些细节不打点、不抓包、不对比 raft.go 里每一条 if 分支的执行路径，很容易陷入“逻辑看起来对，但集群就是不收敛”的困境。
