状态模式核心是状态转移表，用std::map实现比if-else更易维护；动作应在FSM主类中通过on_enter/on_exit回调执行；避免shared_ptr循环引用，推荐无状态结构+variant；多线程下需atomic状态+CAS及mutex保护跳转流程。
状态模式的核心不是类图，是状态转移表怎么写
直接用 std::map 或 std::unordered_map 建立 {当前状态, 事件} → 下一状态 映射，比硬写一堆 if-else 或虚函数更易维护。尤其当状态数 >5、事件类型 >3 时，硬编码状态跳转极易漏分支或写反条件。
实操建议：
- 用
enum class State { Idle, Running, Paused, Error };定义状态，避免整数魔法值 - 事件也定义为
enum class Event { Start, Stop, Pause, Resume, Timeout }; - 转移表声明为
std::map<:pair event>, State> transition_table;</:pair>（C++17 起支持std::pair作 key） - 初始化时集中注册所有合法跳转，比如
transition_table[{State::Idle, Event::Start}] = State::Running;
FSM_C++ 中「动作」该放在哪里执行
状态转移本身不带副作用，但每次跳转前后常需执行动作（如进入 Running 状态要启动定时器，退出时要保存上下文）。别把动作塞进状态类的 handle() 里——那会让状态类膨胀且难以测试。
推荐做法：
立即学习“C++免费学习笔记（深入）”；
- 在 FSM 主类中维护两个回调映射：
std::map<state std::function>> on_enter_;</state>和std::map<state std::function>> on_exit_;</state> - 跳转前先调用
on_exit_[current_state]();，跳转后再调用on_enter_[next_state](); - 若某状态无需进出动作，对应 map 中不插入即可，避免空函数调用开销
- 注意：回调函数捕获外部变量时，确保生命周期长于 FSM 实例，否则容易悬垂
如何避免 std::shared_ptr<state></state> 引发的循环引用
有人习惯让每个状态继承自基类并用 std::shared_ptr 持有，再让 FSM 持有当前状态指针——结果是状态对象又持有 FSM 的 weak_ptr 来触发跳转，稍不注意就形成循环引用，导致内存泄漏。
更轻量的做法：
- 完全不用动态分配状态对象，所有状态是无状态的
struct或空类，只承担策略职责 - 把状态数据（如计数器、时间戳、配置参数）全收在 FSM 主类里，状态类只提供纯函数式接口，例如
bool can_transition_to_idle(const Context& ctx); - 若真需要状态携带数据，用
std::variant<idledata runningdata ...></idledata>配合访问者模式，避免指针管理负担
FSM_C++ 在多线程下最常踩的坑是状态读写不同步
process_event() 看似原子，但实际包含「读当前状态 → 查表 → 写新状态 → 执行 on_enter/on_exit」多个步骤。并发调用时可能一个线程刚读完状态，另一个线程已改写，导致跳转逻辑错乱。
简单有效的保护方式：
- 用
std::atomic<state></state>存储当前状态（前提是State是平凡可复制的 enum），配合compare_exchange_weak实现 CAS 跳转 - 对 on_enter/on_exit 回调，用
std::mutex包裹整个跳转流程（非仅状态变量），因为回调里可能修改共享数据 - 避免在回调中调用可能阻塞或重入
process_event()的函数，否则容易死锁
状态模式真正难的不是结构，而是厘清「谁拥有状态数据」「跳转是否允许重入」「错误事件要不要吞掉还是抛出」——这些细节没想清楚，代码越写越像状态泥潭。
