ThinkPHP实现订单状态流转控制的关键是分离状态合法性校验、转换触发与副作用隔离：定义OrderStateInterface统一接口，各状态类（如PendingState）仅实现自身合法操作并自主返回新状态；状态迁移规则集中配置于config/order_state.php，由StateTransitionValidator校验；事务由服务类（如OrderPaymentService）统一封装，状态类只更新状态字段，副作用通过事件或队列解耦。
ThinkPHP 本身不内置状态机组件，但用它实现订单状态流转控制完全可行——关键不是“有没有现成类”，而是怎么把状态合法性校验、转换触发、副作用隔离这几件事理清楚。
State 类怎么设计才不和 ThinkPHP 模型耦死
别在 Order 模型里写一堆 if ($this->status === 'pending') 或 switch。状态行为应该抽离成独立类，每个类只管自己能响应什么操作。
- 定义统一接口
OrderStateInterface，只声明业务真正需要的几个方法：比如pay(Order $order)、cancel(Order $order)、ship(Order $order) - 每个具体状态类（如
PendingState、PaidState）实现该接口，且只在自己合法时执行动作；不支持的操作直接抛InvalidTransitionException -
Order模型持有一个state属性（类型为OrderStateInterface），所有状态相关调用都走$this->state->pay($this)，而不是自己判断 - 状态切换由状态类内部完成：
PendingState::pay()返回新实例new PaidState()，模型只需更新$this->state = $newState
状态转换规则怎么存才好维护
硬编码在每个状态类里容易漏、难查、改起来要翻多个文件。推荐用配置数组集中管理，再配合运行时校验。
- 在
config/order_state.php中定义允许的迁移路径：['pending' => ['paid', 'cancelled'], 'paid' => ['shipped', 'cancelled']] - 写一个轻量
StateTransitionValidator类，提供canTransition(string $from, string $to): bool方法 - 在状态类的入口方法（如
pay()）里先调用验证器，不合法直接 throw，避免逻辑下沉到每个状态类重复写 - 数据库中保留
order_status_log表记录每次变更，字段含order_id、old_status、new_status、operator、created_at
ThinkPHP 事务 + 状态变更怎么不出错
状态变更常伴随库存扣减、通知发送、支付回调等副作用，一环失败就得整体回滚。ThinkPHP 的事务机制得用对地方。
立即学习“PHP免费学习笔记（深入）”；
- 不要在状态类里直接调用
Db::transaction()—— 状态类只负责状态字段更新和基础校验 - 把整个业务流程封装进服务类（如
OrderPaymentService），在它的公共方法里开启事务：Db::transaction(fn() => $this->handlePayment($order)) - 状态变更（
$order->state->pay($order)）放在事务块内，且确保它只改$order->status和$order->state，其他操作（如发消息、调第三方）通过事件或异步队列解耦 - 如果支付回调需幂等处理，状态类的
pay()方法应先检查当前是否已是paid，避免重复更新
为什么 match 表达式不适合这里
PHP 8.0+ 的 match 看似简洁，但它只是分支选择，不解决状态自治、可测试性、扩展性问题。
-
match($order->status) { 'pending' => fn() => $this->doPay(), ... }仍把所有逻辑堆在一处，加个“已退款”状态就得改这个 match 块 - 无法在
pending状态下拦截ship()调用并给出明确错误上下文（比如 “待支付订单不能发货”） - 单元测试时，你得 mock 整个
Order对象来测不同分支；而用状态类，可以直接 newPendingState测它的ship()是否抛异常 - 当某个状态需要带条件迁移（如“仅未超时订单可取消”），
match很快会膨胀出嵌套if，失去初衷
状态机最难的不是写代码，是把“谁该决定能不能做某事”这件事划清楚边界。状态类决定合法性，服务类管事务与副作用，模型只做数据载体——ThinkPHP 的灵活性反而让这三者更容易各司其职，而不是被框架带着走。
