订单状态机应使用独立 orderstatemachine 类作决策中枢，behavior 仅用于状态校验或快捷方法；状态变更必须走统一入口，副作用通过 transaction::oncommit 延迟触发，确保事务一致性。
订单状态机该用 Behavior 还是独立 Service？
直接在 Order 模型里写一堆 if-else 判断状态流转，或者把所有逻辑塞进 OrderService 一个类里，短期能跑，长期必崩。Yii 的行为（Behavior）适合封装「与模型生命周期强相关、但又不该属于模型本身职责」的逻辑；而状态机的核心是「决策+副作用」——比如支付成功后要扣库存、发通知、记日志，这些动作跨层且有上下文依赖，不适合只靠 Behavior 承担。
推荐做法：用独立的 OrderStateMachine 类做状态决策中枢，再通过事件（如 Order::EVENT_STATUS_CHANGED）解耦后续动作。Behavior 可用于自动绑定状态字段校验或提供快捷方法（如 $order->canShip()），但不负责执行流转。
- 别在
Order::beforeSave()里硬编码状态跳转逻辑——它无法区分是用户调用还是后台脚本触发 - 避免把
transitionToPaid()这类方法直接挂在Order上，否则测试时得 mock 整个模型实例 - 状态变更必须走统一入口（如
$stateMachine->apply($order, 'paid', $context)），确保前置检查、日志、事件触发全部可控
怎么让状态流转支持事务安全和回滚一致性？
Yii 默认的数据库事务（$transaction = Yii::$app->db->beginTransaction()）不会自动保护你手动写的日志或 Redis 缓存操作。如果状态更新成功但后续发消息失败，你得靠补偿；但如果日志表先写了、事务又回滚了，就会出现「日志有记录、订单没变」的脏数据。
关键不是“能不能写”，而是“什么时候写”。必须等事务真正提交后再触发状态变更的副作用。
- 用
Transaction::onCommit()回调注册日志写入和事件触发，而不是在save()后立刻调用trigger() - 不要在事务内调用异步任务（如
Yii::$app->queue->push(...)），除非队列驱动本身支持事务绑定（如 DB 队列 + onCommit） - 若使用 Redis 更新缓存状态，需在
onCommit中执行，或改用延迟双删策略（先删缓存，事务提交后再删一次）
状态定义用枚举类还是数据库配置表？
用 PHP 枚举（enum OrderStatus: string）最轻量，也最利于 IDE 提示和类型检查，但硬编码状态意味着加个“部分发货”就得改代码、发版。数据库配置表（order_status）灵活，可动态启停状态、配权限，但每次查状态都要多一次 DB 查询，还容易因缓存失效导致状态名错乱。
折中方案：状态值（如 'shipped'）用枚举保证类型安全，状态元信息（是否允许用户取消、谁有权操作、前端显示名）存在数据库，并用 yii\caching\CacheDependency 缓存，10 分钟自动刷新。
- 枚举值必须和数据库字段类型一致（建议全小写字符串），避免大小写混用导致
match失败 - 禁止在枚举里写业务逻辑（如
public function canCancel(): bool { return $this === self::PAID; }）——状态规则会变，逻辑应由状态机类判断 - 前端展示文案不要从枚举注释读取，统一走 i18n 翻译文件，否则中英文切换时状态码含义就对不上
事件监听器里怎么避免重复消费和循环触发？
订单从 paid → shipped 时，Order::EVENT_STATUS_CHANGED 被触发，监听器里调用了 InventoryService::decrease()，而库存扣减又触发了另一个事件，结果又回到订单状态机……这种隐式调用链一旦形成，调试起来就是地狱。
根本解法不是禁用事件，而是明确边界：状态机只负责“当前这一步是否允许发生”，不负责“这一步之后该做什么”。后续动作全部交给显式监听器，且监听器内部必须做幂等控制。
- 监听器开头加唯一键判重：用
"order_{$order->id}_{$event->name}_{$order->status}"做 Redis 锁，过期时间设为 5 分钟 - 禁止在监听器里调用可能再次触发
EVENT_STATUS_CHANGED的方法（如$order->save()）；如需更新，用updateAll()绕过模型生命周期 - 敏感操作（如发短信、调支付回调）必须记录
outbox表，由定时任务轮询发送，而非监听即发
