状态机应优先用类封装，因需管理上下文、复用逻辑及响应外部事件；函数指针数组易越界且难控生命周期；含数据成员或需事件钩子时必须用类；switch+enum class+default断言更安全。
状态机该用类封装还是函数指针数组
用类封装更可控，函数指针数组容易失控。C++里状态机不是“选个结构就行”，而是看状态迁移是否带上下文、是否需复用、是否要响应外部事件。
常见错误现象：std::function 存一堆匿名 lambda 导致对象生命周期难管理；用 void(*)() 函数指针数组时，状态跳转写成 states[next_state]() 却忘了检查 next_state 越界。
- 有数据成员（比如计数器、缓存 buffer）→ 必须用类，状态函数作为
private成员方法 - 纯跳转逻辑（如协议解析的 3 个固定状态）→ 可用
std::array<:function>, N></:function>，但初始化必须全非空，否则调用时报std::bad_function_call - 需要从外部触发事件（如
on_keypress()）→ 类里加virtual事件钩子，别把事件分发逻辑塞进状态函数内部
怎么避免状态跳转时漏掉 break 或 return
用 switch 写状态机最常翻车的地方不是语法错，是少写 break 导致意外穿透，或在 if-else if 链里忘了兜底 else 处理非法状态。
使用场景：嵌入式轮询式状态机、游戏 AI 的行为切换。
立即学习“C++免费学习笔记（深入）”；
- 强制用
enum class State { Idle, Running, Paused };，编译器能帮你 catch 未覆盖枚举值（配合-Wswitch-enum） - 每个
case块末尾加// fallthrough注释，没这行就警告 —— GCC/Clang 都支持-Wimplicit-fallthrough - 别写
if (state == Idle) { ... } else if (state == Running) { ... }，改用switch (state)+default: assert(false);，运行时暴露问题比静默跳到未知分支强
std::variant + std::visit 能不能替代传统状态机
能，但只适合状态极少（≤4）、迁移逻辑极简、且不关心执行顺序的场景。它本质是“状态数据建模”，不是“控制流建模”。
性能影响：每次 std::visit 有间接调用开销，比直接调用成员函数慢 10%–20%；兼容性上 C++17 起可用，但 MSVC 2017 初版对 std::variant 的 SFINAE 支持有 bug。
- 适用：配置解析器的状态（
ReadingKey/ReadingValue/Done），每个状态只干一件事，无循环或条件跳转 - 不适用：TCP 连接状态机（
SYN_SENT→ESTABLISHED→CLOSE_WAIT→ …），迁移路径多、条件耦合深 - 参数差异：
std::variant存的是“当前状态的数据快照”，不是“可执行的行为”；想在状态里存回调？得塞std::function，又回到生命周期问题
调试状态机时怎么看清实际走哪条路径
别靠 print，print 容易被优化掉或淹没在日志里。真正在意路径，就得让状态跳转本身可观察、可拦截。
容易踩的坑：在每个状态函数开头打 printf("in Running\n")，结果发现输出顺序和预期不符——其实是异步任务调度或重入导致的。
- 加一层薄薄的跳转记录：在基类里定义
virtual void on_state_changed(State from, State to)，派生类按需 override 记录到环形缓冲区 - 用
__builtin_return_address(0)+backtrace_symbols抓调用栈（仅调试版），比字符串匹配靠谱 - 关键状态点加
assert(state_ == ExpectedState)，别等出错了才查——状态机的错往往延迟暴露
复杂点在于状态可能被多个线程修改，或被中断打断。这时候加锁不是解法，真正要的是明确“谁负责驱动状态变迁”，把驱动逻辑收口到单一入口点，比如 process_event(const Event& e)。其他地方只读状态，不写。
