std::mutex不能直接保护FSM的transition()函数，因其不支持递归加锁，状态回调中再调用transition()会导致同线程死锁；需分离状态迁移与副作用执行，用std::atomic保证状态变量原子性。
为什么 std::mutex 不能直接保护 FSM 的 transition() 函数
可重入性不是“加锁就能解决”的问题。如果在状态处理函数中（比如 on_enter_state_B()）又调用了 transition()，而该函数持有 std::mutex，就会导致同一线程重复加锁——std::mutex 不支持递归，直接死锁或未定义行为。
真正需要的是「线程安全 + 可重入」的协同机制，核心思路是：不阻塞调用者，也不依赖锁来串行化状态流转逻辑。现代 C++ 的解法是把状态迁移决策和副作用执行分离：
- 所有
transition()调用只修改内部状态变量（如m_current_state），不执行任何用户回调 - 用户回调（
on_exit_*/on_enter_*）统一延迟到一个明确、可控的时机执行，比如在事件循环 tick 或显式调用process_pending_transitions() - 状态变量本身用
std::atomic<state></state>保证读写原子性（前提是State是平凡可复制的枚举）
如何用 std::variant 和 std::visit 替代传统 switch-case 状态分发
硬编码 switch (state) { case A: ... case B: ... } 会破坏开闭原则，每次新增状态都要改所有分发点。用 std::variant<statea stateb statec></statea> 把状态建模为类型，能获得编译期检查和自动补全支持。
关键在于封装一层访问器：
立即学习“C++免费学习笔记（深入）”；
struct StateVisitor {
void operator()(const StateA&) { /* handle A */ }
void operator()(const StateB&) { /* handle B */ }
void operator()(const StateC&) { /* handle C */ }
};
// 使用时：
std::visit(StateVisitor{}, m_state);
这样新增状态只需加一个重载函数，无需动原有逻辑；且编译器会报错提醒你漏掉某个状态的处理，比运行时崩溃更早暴露问题。
为什么 FSM 的事件处理函数不该返回 bool 表示“是否消耗事件”
返回 bool 看似简洁，但实际埋下三类隐患：
- 调用方必须显式检查返回值，漏判就导致事件被意外吞掉或重复处理
- 无法区分“拒绝迁移”“暂不处理”“错误发生”等语义，全都压缩成
false - 与 RAII 冲突：若在
on_enter_X()中抛异常，transition()的中间状态可能已部分提交，难以回滚
推荐用强类型枚举表达意图：
enum class TransitionResult { Accepted, Rejected, Deferred, Error };
// 然后让每个状态的 handler 返回这个 enum
TransitionResult handle_event(const Event& e) override;
配合 std::expected<newstate error></newstate>（C++23）或自定义结果类型，能把迁移失败的原因带出来，方便上层做重试、降级或日志追踪。
如何避免 shared_ptr<this></this> 在状态回调中引发循环引用
常见错误是让状态处理器捕获 shared_from_this()，比如：
auto self = shared_from_this();
m_timer->async_wait([self](error_code ec) {
self->transition(StateB{}); // 持有 self，延长自身生命周期
});
一旦定时器没被及时 cancel，对象就永远无法析构。解法很直接：
- 状态处理器一律用
weak_ptr<this></this>捕获，进入回调第一行先lock() - FSM 类自身不继承
enable_shared_from_this，除非明确需要被外部持有 - 对异步操作，优先用 move-only 的 lambda + 值捕获（如
[state = std::move(new_state)]），彻底切断对象生命周期依赖
可重入 FSM 的脆弱点不在状态逻辑本身，而在回调与资源生命周期的耦合。盯住 shared_ptr 的流向，比优化状态跳转路径重要得多。
