C++实现简单的状态机(FSM) _ switch与状态模式对比【源码】-C++-PHP中文网

switch实现fsm仅适用于状态≤4个、每状态事件≤2种的简单场景；超限时易因漏break、状态变量混乱等崩溃，应优先考虑std::function状态表或状态模式。

c++实现简单的状态机(fsm) _ switch与状态模式对比【源码】

直接用 switch 在一个函数里跳转状态，对简单逻辑（比如按钮长按/短按、协议帧接收的几个固定阶段）完全够用，代码写起来也快。但一旦状态数超过 5 个，或者每个状态里要处理多个事件（比如“收到 A 事件干啥，收到 B 事件又干啥”），switch 嵌套就会迅速失控。

常见错误现象：case 漏写 break 导致意外穿透；状态变量被多处修改，难以追踪当前实际状态；新增状态要改一堆 case 和条件判断，容易漏掉某个分支。

实操建议：

比纯 switch 更易维护，又比完整状态模式更少样板代码。核心是用一个 std::map 或数组存“状态 → 处理函数”，每次根据当前状态查表调用，函数内部决定是否切换状态。

使用场景：需要动态增删状态（比如插件式协议解析）、状态行为差异大但不想写一堆类、团队里有人不熟悉设计模式。

实操建议：

当状态之间共享大量上下文数据（比如网络连接中的缓冲区、重传计数器、超时定时器），且不同状态对同一事件的响应逻辑差异极大（比如“断连状态收到数据包”和“已连接状态收到数据包”几乎完全无关），这时候硬塞进一个函数或函数表，会导致参数膨胀、逻辑纠缠。

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

性能影响：每个状态一个对象，频繁切换状态可能触发小对象分配（如果堆上 new）；但若用栈上对象或对象池管理，开销可控。

实操建议：

状态类继承自抽象基类，但基类只暴露 handle(Event&) 和 on_entry()/on_exit()，别塞太多虚函数
上下文（Context）持有指向当前状态的 std::unique_ptr<state></state> 或 State&（后者需确保生命周期）
避免状态类之间互相持有对方指针——用 Context 中转，否则容易循环依赖或悬空
调试时打日志别只打“进入 X 状态”，要带上下文关键字段，比如 [TCP] state=ESTABLISHED, snd_una=1024, rtt=42ms

如果你的状态数固定、类型差异明显（比如 “未初始化 / 正在加载 / 加载成功 / 加载失败”），且想靠类型系统在编译期拦住非法状态转换，std::variant 是比虚函数更轻量的选择。

容易踩的坑：每次访问都要 std::visit，嵌套深了可读性下降；不能像类那样自然封装行为，得靠访客函数组织逻辑；不支持运行时动态添加新状态类型。

实操建议：

把状态 variant 放在结构体里，别裸用 std::variant<a></a>，方便后续加字段
用 std::visit([](auto&& s) { ... }, state_) 的泛型 lambda，避免为每个状态写重复 if constexpr
状态变更用 std::visit 返回新 variant，配合 std::exchange 原地替换，避免拷贝
单元测试时，对每个状态分支单独构造 variant 实例验证，比 mock 状态类更容易覆盖边界

状态机不是越“模式化”越好。开关多、路径少、状态生命周期短，switch 就是正解；上下文重、行为散、要长期演进，才值得铺状态模式。最常被忽略的是：状态迁移条件本身是否稳定——如果“从 A 到 B”的条件下周就要改成“A 且超时 > 5s 才能到 B”，那再漂亮的状态类也会被条件分支撕碎。