如何用C语言实现状态机模式处理复杂订单流，实现状态模式类切换逻辑实战？

本文共计1108个文字，预计阅读时间需要5分钟。

状态机模式在订单系统中不是炫技的选择，而是避免使用if-else堆叠成意义不大的代码的必要手段。直接输出结论：

为什么必须用多态状态类，而不是 enum + switch

订单状态流转不是线性链条（比如 Created → Paid → Shipped → Delivered），而是存在条件跳转、并行子状态（如“支付中”可能因超时回退到“待支付”，也可能被人工干预强制置为“已作废”）。用 enum 驱动 switch 会导致：

• 每个业务方法（pay()、cancel()、refund()）里都要写一遍完整状态判断逻辑，重复且易错
• 新增状态（如“部分发货”）需同步修改所有方法的 switch，编译期不报错，运行时才暴露逻辑缺失
• 无法封装状态专属行为——比如“已发货”状态才允许调用 generateTrackingNumber()，但 enum 模式下这个函数得放在主订单类里，靠 if (state == SHIPPED) 控制，破坏职责分离

状态类设计要点：接口统一、转移可控、生命周期明确

每个状态继承自抽象基类 OrderState，只暴露当前合法操作，禁止非法调用。关键不是“能做什么”，而是“不能做什么”——编译期就拦住错误。