优先用 class 封装状态机；函数指针数组仅适用于极简无状态嵌入式场景，c++ 中易失控、难维护、无法存上下文，而 class 可整合状态、逻辑、守卫条件并支持编译器优化。
状态机该用类封装还是函数指针数组
直接说结论：优先用 class 封装，别碰裸的函数指针数组。后者看着轻量，实际一加条件分支、状态间数据传递、调试日志，立刻失控。
函数指针数组适合只有 3–4 个无状态跳转的嵌入式小场景（比如 LED 模式切换），但 C++ 里几乎没优势：没法存上下文，不能重载，std::function 一上反而更重；而 class 可以把状态变量、转换逻辑、守卫条件全收在内部，编译器还能做内联优化。
- 错误现象：
void (*transitions[5])(void)改着改着变成“谁调用了谁”都理不清，加个新状态就得全局改数组长度和索引常量 - 实操建议：每个状态建一个私有方法，如
handle_idle()、handle_running()，用enum class State { Idle, Running, Paused }管理当前值 - 注意
switch (state)不要漏default分支——C++ 不保证枚举值连续，未定义行为可能静默跳到错误地址
如何避免状态跳转时的数据竞争
多线程下最常踩的坑不是状态值本身，而是「状态已变，但对应数据还没就绪」。比如从 Connecting 切到 Connected，网络句柄却仍是空指针。
根本解法不是加锁，而是让状态变更成为原子操作：状态字段和它依赖的数据必须一起更新，且对外不可见中间态。
立即学习“C++免费学习笔记（深入）”；
- 错误现象：在
set_state(State::Connected)里只改了m_state，后续靠外部再调init_network()—— 这之间任何地方读状态都会拿到“假连接” - 实操建议：把状态变更封装成带参数的方法，如
transition_to_connected(int fd, const std::string& addr)，内部先初始化数据，再改状态 - 如果必须异步触发跳转（比如 IO 完成回调），用
std::atomic<state></state>+ CAS 循环，但仅限简单状态；复杂逻辑一律走事件队列或状态机主循环
std::variant 实现状态机是否值得
值得，但仅当状态种类少（≤5）、每种状态的数据结构差异大、且你愿意放弃部分运行时灵活性。它本质是类型安全的 union，比 void* 强，比完整类封装弱。
典型适用场景：协议解析器里，不同报文类型（Handshake / DataPacket / Ack）需要完全不同的字段和处理逻辑，且不共享状态变量。
- 错误现象：用
std::variant存状态枚举 + 一堆std::any字段，结果每次访问都要std::visit+ 类型检查，性能差还难 debug - 实操建议：每个变体类型自己是完整 struct，含自己的处理方法，例如
struct Connected { int socket; void send(); };，状态机只管调度，不掺和数据 - 注意
std::variant的拷贝开销——如果某个状态携带大对象（如std::vector<uint8_t></uint8_t>），频繁切换会触发内存分配，此时不如用指针 +std::unique_ptr
为什么 switch-case 状态机容易漏处理边界
因为人脑不擅长穷举所有输入组合。尤其当状态转移受多个条件影响（比如 “收到包 && 校验失败 && 重试次数 switch 套 if 很快变成意大利面条。
真正可靠的写法是把转移逻辑显式建模：用二维表（std::map<:pair event>, State></:pair>）或策略函数对象，让编译器/静态分析能帮你抓漏。
- 错误现象：新增一个
Event::Timeout，只在Running分支加了处理，忘了Idle和Paused下也要响应——运行时崩溃前毫无提示 - 实操建议：定义所有合法
Event枚举，在每个状态处理函数末尾加assert(false)或抛异常，确保未覆盖路径不会静默忽略 - 更稳的做法：用编译期检查，比如
std::array<:array num_events>, NUM_STATES></:array>，初始化时填满，链接时报错提醒缺项
状态机最难的从来不是写跳转逻辑，而是让“不可能发生的状态”真的不可能发生——这需要设计时就堵死隐式假设，而不是靠测试去撞。
