结论：C++实现Raft时应避免裸指针，优先用std::vector、std::unique_ptr等RAII容器和值语义；仅在跨线程或生命周期不确定时谨慎使用std::shared_ptr。
直接说结论：在 C++ 实现 Raft 时，不推荐用裸指针管理核心状态，尤其不能用 new / delete 手动分配节点、日志、任期等关键对象；应该优先用 RAII 容器（如 std::vector、std::unique_ptr）+ 值语义，配合引用或 std::shared_ptr 仅在跨线程/生命周期不确定的场景下谨慎使用。
为什么裸指针在 Raft 状态管理中容易出问题
Raft 节点状态（RaftState）、日志条目（RaftLogEntry）、心跳定时器、RPC pending 队列等，都要求强生命周期确定性与异常安全。裸指针会放大三类风险：
- 忘记
delete→ 内存泄漏，长期运行后 OOM（尤其日志持续追加时） - 多个裸指针指向同一块内存 → 重复
delete或访问已释放内存（比如 Leader 切换时旧日志缓冲区被误删） - 异常抛出路径未覆盖
delete→ 析构不完整，状态机卡在中间态（如appendLog中抛异常，但log已部分写入）
std::vector<RaftLogEntry> 比 RaftLogEntry* 更适合日志存储
日志是 Raft 的核心数据结构，需支持随机索引（查 lastLogIndex）、尾部追加、前缀截断（truncatePrefix）。裸指针数组无法安全支持这些操作：
-
std::vector自动管理容量增长，push_back不会因 realloc 导致迭代器失效（只要不触发 reallocation，而 Raft 日志通常预分配 buffer） - 截断操作只需
log.erase(log.begin(), log.begin() + index)，语义清晰且异常安全 - 若用
RaftLogEntry* log_+size_t len_，则每次truncate都要memmove+ 手动维护长度，极易越界或漏更新 - 序列化快照时，
std::vector可直接data()获取连续内存，裸指针还需额外记录起始地址和长度
哪些地方可以且应该用 std::shared_ptr
仅当对象生命周期跨越异步边界、且所有权不明确时，才引入共享所有权：
立即学习“C++免费学习笔记（深入）”；
- RPC 回调上下文：比如
AppendEntriesAsync发送后，回调函数需访问当前Term和commitIndex，此时可传入std::shared_ptr<RaftNode>避免悬垂引用 - 网络连接句柄：如基于 libuv 或 asio 的 socket 封装类，其生命周期由事件循环管理，用
std::shared_ptr<Connection>保证连接关闭时资源自动释放 - 避免在
RequestVoteRPC 中传递裸this指针 —— 若选举过程中节点状态突变（如收到更高 Term 心跳），裸指针可能指向已销毁对象
RAII 封装状态机与持久化句柄更可靠
Raft 要求日志和 currentTerm、votedFor 等元数据落盘。裸指针无法表达“文件句柄必须在状态析构前关闭”这一约束：
- 用
class PersistentStorage封装FILE*或int fd，构造时打开，析构时fsync+close，确保崩溃后数据不丢失 -
RaftNode成员变量声明为std::unique_ptr<PersistentStorage> storage_，而非PersistentStorage*，避免忘记初始化或释放 - 心跳超时器若用
std::thread+std::atomic_bool控制，应把 timer 对象封装进 RAII 类，停用时自动join()，否则线程分离后访问已销毁的RaftNode成员会 crash
真正棘手的不是“怎么用指针”，而是“哪些状态必须严格绑定生命周期”。Raft 的正确性依赖于状态变更的原子性（如 currentTerm 更新必须伴随 votedFor = null），裸指针会让这种约束在代码中不可见、不可验证。用值语义和 RAII，错误会在编译期或析构期暴露，而不是在集群运行三天后因某次网络抖动突然脑裂。
