Raft强同步靠matchIndex和多数派确认而非加锁或超时；选举失败主因是m_currentTerm落后或m_votedFor锁死。
强同步不是靠加锁或等超时，而是靠 Raft 的 matchIndex 和多数派确认逻辑；选举切换失败的主因往往不是网络，而是 m_currentTerm 落后或 m_votedFor 锁死。
怎么让日志真正“强同步”到多数节点
Raft 的“强同步”本质是：Leader 必须确认某条日志已复制到集群中超过半数节点（含自己），才允许推进 m_commitIndex。这不是靠发完就认为成功，而是依赖每个 Follower 返回的 matchIndex 值做实时判断。
-
matchIndex[i]表示 Leader 认为节点i已成功复制到的日志索引，它只会在收到对应AppendEntriesReply.Success == true且reply.matchIndex更新后递增 - Leader 每次心跳或批量追加后，需重新计算“多数派索引”：对所有
matchIndex（含自身）排序，取第 ⌊n/2⌋+1 大的值；若该值 >m_commitIndex且对应日志的Term等于当前m_currentTerm，才安全提升m_commitIndex - 常见错误是直接用
lastLogIndex或忽略Term校验——这会导致旧任期日志被错误提交，破坏安全性 - C++ 实现中，
matchIndex和nextIndex必须用原子变量或带锁访问，否则并发追加日志时可能读到撕裂值
选举失败时为什么新 Candidate 总是收不到投票
不是因为网络不通，而是候选节点在发起 RequestVote 前没完成关键状态同步：任期未升、本地投票未锁定、或日志不够新。
- 必须先执行
++m_currentTerm并落盘（调用persist()），再设置m_votedFor = m_me；否则其他节点收到请求时发现term ，直接拒绝 -
RequestVoteArgs中的lastLogTerm和lastLogIndex必须取自本地m_logs.back().Term和m_logs.size()，不能用缓存值——Follower 会用这两个字段判断“你有没有资格参选” - 如果节点刚从崩溃恢复但没加载持久化状态（如
m_currentTerm还是 0），它会以旧任期发起投票，所有节点都会返回term: currentTerm让它更新，但它自己不处理这个响应，陷入静默 - gRPC 调用
sendRequestVote必须异步 detach，但 reply 回调里要检查reply.term > m_currentTerm并立即触发状态重载，否则可能错过 term 跳变
心跳超时与选举超时为什么必须随机化
固定超时会导致多个 Follower 同时转为 Candidate，引发反复选举失败（election storm），尤其在网络抖动时放大问题。
- 选举超时建议设为 150–300ms 区间内均匀随机，心跳间隔固定为 50ms；两者差值必须大于网络往返毛刺上限（通常 ≥2×RTTp99）
- C++ 中不要用
std::rand()，而应使用线程局部的std::mt19937配合std::uniform_int_distribution生成每次重启后的独立随机序列 - 注意：随机化只作用于 Follower 的
m_electionTimeout初始值，一旦开始选举，该轮超时值就冻结，避免中途又超时重入doElection - 如果所有节点启动时间接近（如容器批量拉起），即使随机化也可能撞上同一毫秒级窗口——此时需引入基于节点 ID 的哈希偏移，例如
baseTimeout + (m_me % 10) * 5
最易被忽略的一点：m_commitIndex 提升后，必须通过 applyChan 异步通知应用层（如 KVServer），但 C++ 中若用阻塞队列且消费者卡住，整个 Raft 状态机会被拖慢甚至死锁；务必用带超时的 try_push 或无锁环形缓冲，并监控 applyChan 积压深度。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
