结论是：用 hashicorp/raft 实现状态机复制，核心在于正确实现 Fsm 接口与 Apply 语义边界——需自行去重、避免阻塞 I/O、确保返回值可序列化；快照必须完整 dump 并清空旧状态后全量 restore；Transport 地址与超时配置须严格匹配网络实际。
直接说结论：用 hashicorp/raft 实现状态机复制，核心不是写 Raft 算法，而是正确实现 Fsm 接口和处理 Apply 的语义边界。多数人卡在日志回放不一致、快照恢复失败、或 client 请求重复提交上。
如何让 Apply 函数真正“只执行一次”
Apply 是状态机实际变更的唯一入口，但它不是原子调用——节点重启后可能重放已执行过的日志项。Raft 不保证幂等，只保证顺序和一致性。
- 必须在
Fsm.Apply中自行判断该LogEntry是否已处理：常见做法是用单调递增的logIndex或嵌入的客户端请求 ID 做去重（如写入前查本地map[uint64]bool或持久化到StableStore） - 不要在
Apply里做阻塞 I/O（比如 HTTP 调用），否则会拖慢整个 Raft 主循环；需要异步落库时，用 channel + goroutine 转发，但要确保顺序不乱 -
Apply返回的interface{}会被传给 client 的Future.Response()，所以返回值必须可序列化（避免指针、chan、func）
快照（Snapshot）为什么总在恢复后丢数据
快照不是“备份”，而是 Raft 日志压缩的中间态。如果 Fsm.Restore 没正确覆盖已有状态，或 Snapshot 生成时漏掉了未 apply 的日志，重启后就会回退到旧状态。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
Fsm.Snapshot必须在状态锁保护下完整 dump 当前内存状态（比如 map 深拷贝），不能边读边写 -
Fsm.Restore必须清空旧状态再加载快照内容，不能 merge —— Raft 要求快照是“截至某 index 的完整状态快照” - 检查
raft.Config.SnapshotThreshold和SnapshotInterval：默认值（8192 / 30s）在小负载下容易触发过频快照，反而增加 IO 压力
TCP transport 下节点连不上 leader 怎么快速定位
不是 DNS 或防火墙问题，大概率是 Transport 初始化时地址绑定或心跳配置错位。
立即学习“go语言免费学习笔记（深入）”；
- 确认每个节点的
transport.LocalAddr是监听本机可访问地址（如:8080），不是127.0.0.1:8080—— 后者只接受本地连接 - 检查
raft.Config.HeartbeatTimeout和ElectionTimeout：必须满足HeartbeatTimeout ，且两者都应大于网络 RTT 的 2~3 倍；设成 500ms / 1s 在局域网常见，但跨云环境需上调 - 启动后立刻查
raft.Stats()输出的leader、state、lastContact字段，比看日志更快发现是否卡在 follower 状态或失联
Raft 的难点从来不在选举或日志复制逻辑本身，而在于你如何定义“状态”、怎么切分“命令”、以及是否意识到 Apply 和 Restore 共享同一份状态视图——它们之间没有事务隔离，出错时只能靠你自己的代码兜底。
