最小可行Raft选举模型需用channel和goroutine实现心跳、超时、投票闭环，状态变更须经StateChange通道广播，term与votedFor需原子化读写，避免竞态；超时用time.Timer并Reset，禁用未Stop的time.After；测试需模拟时钟漂移与网络分区。
Go里用channel和goroutine模拟Raft选举的最小可行模型
想靠Go原生特性快速验证选举逻辑，别急着写网络通信——先用channel和goroutine搭出心跳、超时、投票三要素闭环。真实分布式系统里网络延迟不可控，但本地模拟能暴露状态竞争和超时逻辑漏洞。
常见错误现象：select里漏写default分支导致goroutine永久阻塞；time.After在循环里反复创建却不Stop()，引发定时器泄漏。
- 每个节点用一个
struct封装currentTerm、votedFor、state（follower/candidate/leader）字段 - 心跳超时用
time.Timer而非time.After，便于在收到心跳后调用Reset() - 投票请求走
chan RequestVoteArgs，响应走chan RequestVoteReply，避免锁竞争 - 所有状态变更必须通过同一
chan StateChange广播，禁止直接赋值
为什么sync.Mutex在选举临界区经常不够用
单纯给currentTerm加锁，挡不住candidate在发起投票前已读到旧term、发完请求后才被其他节点更新term的竞态。Raft要求“term递增”和“投票幂等”必须原子化。
使用场景：当节点收到RequestVote请求，需同时检查term <= candidateTerm且votedFor == nil || votedFor == candidateId，这两个判断不能拆开。
立即学习“go语言免费学习笔记（深入）”；
- 把
term和votedFor合并进一个atomic.Value或用sync.RWMutex配struct{ term int; votedFor string }整体读写 - 拒绝旧term请求时，必须立即更新本地
currentTerm并降级为follower——这个动作不能滞后于返回响应 - 测试时故意让两个candidate几乎同时触发选举，观察是否出现双leader，这是检验锁粒度是否足够的关键压测点
etcd raft库不是黑盒，关键接口必须自己补全
直接调raft.NewNode()只能拿到基础状态机，但真实选举依赖你提供Storage实现和Transport适配。官方示例常省略持久化细节，导致重启后term归零、选票丢失。
参数差异：raft.Config里的ElectionTick和HeartbeatTick不是毫秒数，而是tick单位——实际超时时间 = ElectionTick * tickMs，而tickMs由你传入的raft.NewRawNode()的tick函数控制。
-
Storage必须实现InitialState()和Entries()，其中InitialState()要返回上次持久化的HardState（含term/vote/commit） - 网络层用
raft.Transport时，Send()方法不能阻塞——内部需启动goroutine发HTTP/gRPC，否则会卡死raft主循环 - 日志复制和选举共用同一
raft.Node实例，但Propose()只影响leader，Campaign()只影响candidate，别混淆调用时机
测试选举逻辑时最容易忽略的时序陷阱
本地跑10次都成功，一上k8s就脑裂，大概率是没模拟网络分区下的时钟漂移。Kubernetes里pod间RTT波动远大于time.Now().UnixNano()精度，靠绝对时间判断超时必然失效。
性能影响：用time.Since()计算耗时看似合理，但在高负载节点上GC暂停可能导致单次测量偏差20ms以上，而ElectionTick通常设为150ms——一次误判就触发无效选举。
- 测试时用
github.com/jonboulle/clockwork替换time.Now，手动推进虚拟时钟，精确控制follower超时触发时刻 - 注入网络故障用
toxiproxy而非iptables，前者能模拟丢包+延迟+乱序，后者只处理连通性 - 观察
raft.Ready通道输出的Messages字段，真正发送前检查MsgType是否为raft.MsgVote或raft.MsgHeartbeat，别只看日志打印
真正的难点不在写代码，而在定义清楚“什么算一次有效选举完成”——是收到半数+1票？还是收到首个MsgAppendResponse确认日志提交？这个边界不厘清，所有测试都是空中楼阁。
