在 go 中实现可调试的 paxos，关键在于精简干扰项并正确同步 promisenumber：需用 atomic 或 mutex 保护编号字段，否则并发 prepare 会导致 accept 被错误拒绝。
直接说结论：在 Go 中实现一个「能跑通、可调试、不崩溃」的 Paxos，关键不是堆功能，而是先砍掉所有干扰项——不持久化、不真实 RPC、不处理网络分区、不支持多轮提案重试。否则你连 Prepare 阶段的 promiseNumber 更新逻辑都对不上。
为什么不能直接照搬论文伪代码写 Go
论文里的 minProposal 是全局状态，但 Go 里每个 acceptor 是独立 struct；论文说「收到更大编号的 Prepare 就承诺不接受更小编号」，可实际代码中如果没用 atomic.CompareAndSwapInt64 或互斥锁保护 promiseNumber，并发 Prepare 请求会覆盖彼此，导致 Accept 阶段拒绝合法提案。
- 常见错误现象：
Proposer发出Prepare(5)后收到多数Promise，接着发Accept(5, "A")，但部分Acceptor却返回Reject—— 因为中间被另一个Proposer的Prepare(6)覆盖了承诺 - 使用场景：本地多 goroutine 模拟节点时，必须显式同步
promiseNumber和acceptedNumber字段 - 性能影响：用
sync.Mutex最简单，但高并发下会成为瓶颈；atomic更快，但只适用于整型编号（比如用int64编码timestamp）
如何让 Proposer 正确生成和比较 proposal number
proposal number 不是递增整数，而是全局唯一且可比较的序号。用纯时间戳会撞，用 rand.Int() 无法排序，必须带节点标识。
- 推荐做法：定义
type ProposalNum int64，构造函数为func NewProposalNum(id int) ProposalNum { return ProposalNum(time.Now().UnixNano() - 参数差异：
number字段在message结构体里必须是可序列化类型（不能是自定义 type 别名，除非实现encoding.BinaryMarshaler），否则 RPC 会 panic - 容易踩的坑：多个
Proposergoroutine 同时调用NewProposalNum()，若未加锁或未用原子操作生成时间戳低位，可能产生相同编号 → 违反 Paxos 安全性前提
Accept 阶段失败后该怎么处理
收到少于半数 AcceptOK 响应时，Paxos 并不要求立即重试。盲目重试只会加剧冲突，正确做法是：升序找下一个可用编号，再走一遍两阶段。
- 常见错误现象：Proposer 收到 2/5 成功，3/5 拒绝（因被更高编号 Prepare 覆盖），立刻用原编号重发
Accept→ 全部拒绝 - 实操建议：在
Proposerstruct 中维护lastUsedNumber ProposalNum，失败后调用NewProposalNum(id)生成新号，且确保新号 >lastUsedNumber - 兼容性注意：如果 Acceptor 返回了它见过的最高
acceptedNumber（如论文中 Promise 响应带lastAccepted），Proposer 应优先沿用那个值对应的内容，而不是坚持自己原来的value
为什么 Learner 角色常被忽略但不能真删
Learner 不参与投票，但它是共识达成的「见证者」。没有 Learner，你就无法判断某次提案是否真的被多数 Accept —— 所有日志都只显示「我发了」「我收了」，但不知道「是否已决议」。
- 最简实现：每个 Acceptor 在成功 Accept 后，向所有 Learner 发送
Decided{number, value}消息；Learner 收到 ≥ N/2+1 条相同number的Decided，就认为该提案已决议 - 容易被忽略的地方：Learner 必须去重和排序，因为网络可能重复投递；同一
number的不同value是非法的，应触发 panic 或日志告警 - 调试价值：把 Learner 输出打印到终端，是验证 Paxos 是否真正达成一致的唯一可信依据；光看 Proposer 日志全是“sent”和“received”，毫无意义
