状态类必须继承共同接口且不可直接 new，核心是行为委托给当前状态对象；应通过工厂或静态实例管理状态生命周期，context 持有 std::unique_ptr 并提供 setstate()，切换时需先调用 onexit() 再替换指针。
状态类必须继承共同接口，且不能直接 new 具体状态
状态模式的核心是把行为委托给当前状态对象，而不是用 if-else 或 switch 硬编码判断。所以得先定义一个抽象状态接口，比如 State，所有具体状态（IdleState、RunningState）都继承它，并实现统一的 handle() 或 onEvent() 方法。
常见错误是让上下文类（比如 Context）在内部直接 new RunningState() —— 这会导致状态对象生命周期失控、无法共享或复用。正确做法是让状态对象由外部管理，或通过工厂/静态实例提供，确保状态切换时旧状态能被安全替换。
- 状态类应是无状态的（不保存上下文数据），所有依赖的数据从
Context*参数传入 - 避免在状态构造函数里访问
Context的未初始化成员 - c++11 起推荐用
std::unique_ptr<state></state>管理状态生命周期，防止裸指针悬挂
Context 类需持有状态指针并提供 setState() 接口
Context 是用户直接交互的对象，它不自己实现行为逻辑，而是把调用转发给当前 m_state。关键点在于：状态变更必须显式调用 setState()，而不是在某个事件处理中悄悄 new 一个新状态塞进去。
示例中容易漏掉的是：状态切换后，原状态对象可能还持有对 Context 的引用（比如回调注册），若没清理，会引发野指针或重复触发。所以 setState() 应先调用旧状态的 onExit()（如有），再替换指针。
立即学习“C++免费学习笔记（深入）”；
-
setState()接收std::unique_ptr<state>&&</state>，避免拷贝和裸指针传递 - 不要在
State子类里直接修改Context::m_state，破坏封装 - 如果状态需要异步触发切换（如定时器回调），确保
Context生命周期长于回调执行期
避免循环依赖：State 头文件不能 #include Context 实现细节
编译时最常卡住的地方是头文件依赖。比如 RunningState.h 为了调用 context->doSomething()，就 #include "Context.h"；而 Context.h 又要声明 std::unique_ptr<state></state>，于是又 #include "State.h" —— 如果 State.h 里又用了 Context 的具体类型，就成环了。
解法是前向声明 + 指针/引用 + 实现文件延迟包含。在 State.h 中只写 class Context;，函数参数用 Context* 或 Context&；具体调用逻辑全挪到 State.cpp 里，那里才 #include "Context.h"。
- 违反这点会导致编译失败，错误信息常是
invalid use of incomplete type 'class Context' - 别为了省事把所有东西塞进一个 .cpp 文件——状态逻辑分散才利于维护
- 如果
Context接口很大，可考虑抽一个轻量ContextView供状态使用，进一步解耦
std::shared_ptr 不适合做状态管理，除非明确需要共享所有权
有人图方便用 std::shared_ptr<state></state>，觉得自动管理省心。但状态模式里，“当前状态”是排他的：一次只能有一个活跃状态，且切换时旧状态应立即失效。用 shared_ptr 容易掩盖生命周期问题——比如某个异步任务还持着旧状态的引用，导致它继续响应事件，行为错乱。
真正需要共享的不是状态本身，而是状态所依赖的只读数据（如配置、资源句柄）。这些可以单独拎出来，用 shared_ptr 管理，状态对象仍用 unique_ptr 持有它们的弱引用（weak_ptr）或原始指针。
-
unique_ptr强制表达“独占当前状态”的语义，编译器也能帮查空指针解引用 - 若真要用
shared_ptr，务必重载operator==并检查是否指向同一对象，避免误判状态相等 - 调试时打印
m_state.get()地址比打印内容更可靠，因为状态对象通常没重载operator
状态对象的析构时机、跨线程访问、以及事件队列中滞留的老状态指针——这三处最容易出问题，而且一出就是偶发 crash 或逻辑跳变，调试成本远高于前期多写两行生命周期控制。