std::any 不适合直接作状态机上下文，因其缺乏类型安全访问、异常成本高、无并发同步保证；应改用显式结构体+智能指针，或仅用于事件载荷。
为什么 std::any 不能直接当状态机上下文用
因为 std::any 本身不带类型安全的访问语义，每次 std::any_cast 都可能抛 std::bad_any_cast——而状态跳转频繁、多线程并发时，这种异常成本高且难以定位。可重入要求同一实例被多个调用方（比如不同线程或嵌套回调）同时驱动，上下文读写必须原子或无锁，std::any 的内部存储没有同步保证。
实操建议：
- 用
std::shared_ptr包裹一个自定义上下文结构体，而非裸存std::any；该结构体内字段按需声明，避免运行时类型擦除 - 若坚持用
std::any，务必在状态处理函数入口统一做一次std::any_cast并缓存为局部引用，禁止在分支中重复 cast - 不要把
std::any成员放在状态机类的 public 接口里暴露——它会诱使用户绕过状态迁移逻辑直接修改上下文
如何让 FSM 类支持可重入：关键在状态迁移函数的签名
不可重入的 FSM 常把上下文作为成员变量持有，导致 process_event() 调用期间状态和数据耦合。可重入版本必须把上下文作为参数传入每个状态处理器，且处理器返回新上下文（或就地修改并返回引用），让调用方决定生命周期。
示例关键签名：
立即学习“C++免费学习笔记（深入）”；
struct Context { int counter = 0; std::string tag; };
using StateHandler = std::function<Context*(Context&, const Event&)>;
注意点：
- 返回
Context*而非void，允许处理器替换整个上下文对象（比如从登录态切到游客态时清空敏感字段） - 所有状态处理器必须是纯函数式风格：不读写外部静态/全局变量，不依赖 this 指针隐式状态
- 若用
std::shared_ptr<context></context>，确保处理器内不发生循环引用（例如避免把 handler lambda 捕获进 Context）
std::any 在事件携带数据时更合适，而不是存上下文
把 std::any 用在 Event 结构里比用在 Context 里合理得多：事件本就是临时、异构、单次消费的数据载体，类型不确定反而是常态。
典型设计：
struct Event {
std::string type;
std::any payload;
};
// 使用时
if (e.type == "timeout") {
auto ms = std::any_cast<int>(e.payload); // 安全前提：调用方明确知道 payload 类型
}
常见错误：
- 在状态处理器里对
e.payload做多次std::any_cast<t></t>——应一次 cast 成引用后复用 - 把复杂对象（如含虚函数的类）直接塞进
payload，引发 slicing 或析构问题；应传std::shared_ptr或std::unique_ptr - 未检查
e.payload.has_value()就 cast，尤其在跨模块传递事件时，发送方可能忘记赋值
可重入 FSM 的线程安全边界在哪
可重入 ≠ 线程安全。FSM 实例本身可以被多个线程并发调用，但前提是：每个调用方传入独立的 Context 实例，且事件不共享可变数据。真正的并发风险点在三处：
- 状态跳转表（
std::unordered_map<state statehandler></state>）若在运行时动态注册 handler，必须加读写锁 - 若使用全局 logger 或 metrics 计数器，在 handler 内调用时需确认其线程安全性
- 当 Context 中包含
std::shared_ptr指向的共享资源时，资源本身的线程安全不由 FSM 保证——这是使用者责任
最容易被忽略的是：调试打印语句里拼接 Context 字段，若字段是 std::any 且未加锁保护其内部状态（比如自定义类型重载了 operator 但非线程安全），会导致偶发崩溃。
