状态机模式在订单系统中是避免if-else混乱的刚需，应采用虚函数+状态类指针切换而非enum+switch，因后者难以应对非线性流转、易导致逻辑重复与遗漏、破坏封装性。
状态机模式在订单系统里不是“炫技选择”，而是避免 if-else 堆叠成意大利面条代码的刚需。直接结论：用虚函数 + 状态类指针切换最稳，别用枚举+大 switch，后者一加新状态就得改所有分支、漏掉默认处理就崩。
为什么必须用多态状态类，而不是 enum + switch
订单状态流转不是线性链条（比如 Created → Paid → Shipped → Delivered），而是存在条件跳转、并行子状态（如“支付中”可能因超时回退到“待支付”，也可能被人工干预强制置为“已作废”）。用 enum 驱动 switch 会导致：
- 每个业务方法（
pay()、cancel()、refund()）里都要写一遍完整状态判断逻辑，重复且易错 - 新增状态（如“部分发货”）需同步修改所有方法的
switch，编译期不报错，运行时才暴露逻辑缺失 - 无法封装状态专属行为——比如“已发货”状态才允许调用
generateTrackingNumber()，但enum模式下这个函数得放在主订单类里，靠if (state == SHIPPED)控制，破坏职责分离
状态类设计要点：接口统一、转移可控、生命周期明确
每个状态继承自抽象基类 OrderState，只暴露当前合法操作，禁止非法调用。关键不是“能做什么”，而是“不能做什么”——编译期就拦住错误。
- 所有状态类构造函数接收
Order*指针，用于触发状态转移（如order->transitionTo(new ShippedState(order))） -
Order类持有std::unique_ptr<orderstate></orderstate>，确保状态对象随订单销毁，避免裸指针悬挂 - 禁止状态类自行 delete 自己或 new 新状态——转移必须经由
Order::transitionTo()统一入口，防止内存泄漏或野指针 - 重载
operator==或添加type()方法，方便日志打印和单元测试断言（例如EXPECT_EQ(order.state()->type(), "ShippedState")）
transitionTo() 的实现细节决定健壮性
状态切换不是简单替换指针，要防重入、保原子、留痕迹：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 在
transitionTo()开头加assert(next_state != nullptr)，杜绝空状态传入 - 先保存旧状态类型（用于审计日志），再执行
state_.reset(next_state)，避免析构旧状态时异常导致指针悬空 - 若需事务语义（如“支付成功”必须伴随库存扣减），把状态变更和业务动作拆开：
pay()先校验，再调transitionTo()，最后执行扣库存——状态机只管“变”，不管“做” - 调试时在
transitionTo()打印from: [old_type] → to: [new_type]，比查日志快十倍
实际踩过的坑：std::move、const 成员、线程安全
生产环境最常栽在这三处：
- 用
std::move传入新状态对象时，若transitionTo()内部抛异常，移动后的对象处于有效但未定义状态——改用std::make_unique直接构造，绕过移动语义 - 状态类里有
const成员变量（如初始化后不可变的风控策略对象），会导致移动构造函数被隐式删除，编译失败；要么去掉const，要么显式定义移动构造函数 - 订单对象被多线程并发操作（如支付回调和客服后台强制改状态同时到达），
transitionTo()必须加锁——但锁粒度不能是整个订单对象，建议用std::atomic<bool> state_transitioning_{false}</bool>做轻量CAS尝试，失败则重试或排队
状态机真正的复杂点不在类结构，而在“谁有权发起转移”和“转移前是否要查数据库”。这些逻辑永远不该塞进状态类，而应放在 Order 的业务方法里——状态类只回答“我现在能接受什么输入”，不回答“我现在该不该接受”。
