switch实现FSM仅适用于状态≤4个、每状态事件≤2种的简单场景；超限时易因漏break、状态变量混乱等崩溃，应优先考虑std::function状态表或状态模式。
用 switch 实现 FSM：什么时候够用，什么时候会崩
直接用 switch 在一个函数里跳转状态，对简单逻辑（比如按钮长按/短按、协议帧接收的几个固定阶段）完全够用，代码写起来也快。但一旦状态数超过 5 个，或者每个状态里要处理多个事件（比如“收到 A 事件干啥，收到 B 事件又干啥”），switch 嵌套就会迅速失控。
常见错误现象：case 漏写 break 导致意外穿透；状态变量被多处修改，难以追踪当前实际状态；新增状态要改一堆 case 和条件判断，容易漏掉某个分支。
实操建议：
智能模型自动切换 V5.0.2 - 多模态感知，自动识别图片/视频/音频/代码/文本任务，切换最优模型。支持图片理解(qwen3-vl-plus)、视频音频(qwen3.5-plus)、代码(glm-5)、Office文档(MiniMax-M2.5)、推理等场景。零感知切换，无需手动操作。
- 只在状态 ≤ 4 个、每个状态响应事件 ≤ 2 种时考虑
switch方案 - 把状态定义为
enum class，别用裸int，避免误赋值 - 每个
case块末尾强制加break，哪怕后面是default - 不要在
case里直接修改状态变量，统一用返回值或出参更新，便于测试
std::function + 状态表：轻量又可控的折中方案
比纯 switch 更易维护，又比完整状态模式更少样板代码。核心是用一个 std::map 或数组存“状态 → 处理函数”，每次根据当前状态查表调用，函数内部决定是否切换状态。
立即学习“C++免费学习笔记（深入）”；
使用场景：需要动态增删状态（比如插件式协议解析）、状态行为差异大但不想写一堆类、团队里有人不熟悉设计模式。
实操建议：
- 用
std::array<std::function<void(Event&)>, N>替代map，避免哈希开销和查找失败风险 - 事件类型
Event建议用struct+enum class type，别用void*或std::any - 状态切换不通过返回值，而是在处理函数里调用一个外部可设的
set_state(State)回调，解耦更干净 - 初始化时检查数组大小是否匹配状态枚举数量，可用
static_assert防错
状态模式（State Pattern）：什么情况下真值得上类体系
当状态之间共享大量上下文数据（比如网络连接中的缓冲区、重传计数器、超时定时器），且不同状态对同一事件的响应逻辑差异极大（比如“断连状态收到数据包”和“已连接状态收到数据包”几乎完全无关），这时候硬塞进一个函数或函数表，会导致参数膨胀、逻辑纠缠。
性能影响：每个状态一个对象，频繁切换状态可能触发小对象分配（如果堆上 new）；但若用栈上对象或对象池管理，开销可控。
实操建议：
- 状态类继承自抽象基类，但基类只暴露
handle(Event&)和on_entry()/on_exit()，别塞太多虚函数 - 上下文（Context）持有指向当前状态的
std::unique_ptr<State>或State&（后者需确保生命周期） - 避免状态类之间互相持有对方指针——用 Context 中转，否则容易循环依赖或悬空
- 调试时打日志别只打“进入 X 状态”，要带上下文关键字段，比如
[TCP] state=ESTABLISHED, snd_una=1024, rtt=42ms
编译期状态机（std::variant + std::visit）：C++17 起的新选择
如果你的状态数固定、类型差异明显（比如 “未初始化 / 正在加载 / 加载成功 / 加载失败”），且想靠类型系统在编译期拦住非法状态转换，std::variant 是比虚函数更轻量的选择。
容易踩的坑：每次访问都要 std::visit，嵌套深了可读性下降；不能像类那样自然封装行为，得靠访客函数组织逻辑；不支持运行时动态添加新状态类型。
实操建议：
- 把状态 variant 放在结构体里，别裸用
std::variant<A,B,C>，方便后续加字段 - 用
std::visit([](auto&& s) { ... }, state_)的泛型 lambda，避免为每个状态写重复if constexpr - 状态变更用
std::visit返回新 variant，配合std::exchange原地替换，避免拷贝 - 单元测试时，对每个状态分支单独构造 variant 实例验证，比 mock 状态类更容易覆盖边界
状态机不是越“模式化”越好。开关多、路径少、状态生命周期短，switch 就是正解；上下文重、行为散、要长期演进，才值得铺状态模式。最常被忽略的是：状态迁移条件本身是否稳定——如果“从 A 到 B”的条件下周就要改成“A 且超时 > 5s 才能到 B”，那再漂亮的状态类也会被条件分支撕碎。
