C++实现状态机模式处理复杂逻辑 _ 状态接口与类转换技巧【源码】-C++-PHP中文网

状态接口必须用虚析构函数，否则 delete 父类指针会导致子类析构函数不被调用而内存泄漏；状态转换须通过受控的 transition_to() 方法集中管理；避免循环引用应使用 weak_ptr 或回调函数；固定状态集可选 std::variant 实现零开销抽象。

c++实现状态机模式处理复杂逻辑 _ 状态接口与类转换技巧【源码】

如果你定义了 State 接口类但没写虚析构函数，当通过 State* 指针 delete 子类对象时，子类的析构函数根本不会被调用。这是 C++ 状态机最隐蔽的崩溃源头之一。

实操建议：

C++ Code Review Master

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

下载

所有基类状态接口必须声明 virtual ~State() = default;
不要用 std::unique_ptr<state></state> 持有子类对象，除非你确认析构安全；更稳妥的是显式指定删除器：std::unique_ptr<state void></state>，或直接用 std::unique_ptr<concretestate></concretestate> 配合工厂返回具体类型
若用 std::shared_ptr，只要基类有虚析构，就无需额外处理

直接写 current_state = new RunningState(); 是危险的：资源泄漏、异常不安全、状态生命周期失控。C++ 状态机的核心约束是“一次只存在一个活跃状态”，必须集中管理。

实操建议：

在上下文类（如 Context）中封装 transition_to(std::unique_ptr<state> next)</state> 方法，内部先释放旧状态，再接管新状态
避免在状态内部直接调用 context->current_state = ... —— 这破坏了封装，也绕过了清理逻辑
如果状态切换可能失败（比如需校验前置条件），让 transition_to() 返回 bool 或抛异常，而不是静默失败

状态对象若持有一个 Context* 或 std::shared_ptr<context></context>，极易引发循环引用：Context 持有 State，State 又持有 Context → 两者永远无法析构。

实操建议：

用 std::weak_ptr<context></context> 替代 std::shared_ptr<context></context>，每次访问前调用 lock() 判断是否还有效
更轻量的做法是传入回调函数对象，比如 std::function<void></void>，让状态触发事件时不反向依赖 Context 结构
如果状态只需读取少量 context 数据（如配置、ID），考虑在进入状态时拷贝必要字段，彻底解耦

不是所有场景都需要运行时多态。如果你的状态数量固定、不频繁增删，且追求零开销抽象，std::variant 是比虚函数更干净的选择。

实操建议：

定义 using StateVariant = std::variant<idlestate runningstate pausedstate>;</idlestate>，每个状态为普通 struct，不含虚函数
用 std::visit([](auto& s) { s.handle_event(e); }, state_variant) 分发事件，编译器可内联各分支
状态转换变成 state_variant = RunningState{...};，无 new/delete，无虚表查找，RAII 自然生效
缺点：无法在运行时动态加载新状态类型；调试时 std::variant 的类型名较难读，建议配合 std::string_view name() 辅助日志

状态机真正的复杂点不在“怎么写状态类”，而在于“谁负责销毁旧状态”和“状态间如何安全通信”。这两个问题没想清楚前，哪怕接口设计得再漂亮，上线后也会在边界条件上出问题。