订单状态流转必须通过 beforewrite/afterwrite 钩子实现，因二者在事务内可控校验、日志、通知与库存联动；硬改字段或批量 update 会绕过所有逻辑，导致状态机失效。
ThinkPHP 里订单状态流转不能靠 $order->status = 'shipped' 或 where()->update() 硬改，否则校验、日志、通知、库存联动全失效——状态机就成摆设。
为什么 beforeWrite/afterWrite 是唯一靠谱的入口
ThinkPHP 模型的生命周期钩子是业务与状态强绑定的唯一可控位置。数据库触发器看不到上下文，定时任务有延迟，而控制器里裸赋值直接绕过所有约束。
-
beforeWrite在数据写入前执行，适合做状态合法性校验（比如禁止从'shipped'直接跳回'paid'） -
afterWrite在数据已落库、事务未提交时触发，适合发消息、扣库存、写操作日志——此时$order->id可靠，且失败会自动回滚 - 两个钩子都在事务内，但第三方调用（如微信回调通知）必须单独处理幂等，不能直接塞进
afterWrite
怎么写 beforeWrite 才真正拦截非法跳转
关键不是判断“当前是不是 A 状态”，而是比对“旧值 → 新值”是否在允许路径中。ThinkPHP 提供 getOriginal('status') 获取原始值，必须用它，而不是查一遍数据库。
- 在模型中定义合法转移表：
protected $validTransitions = ['pending' => ['paid', 'cancelled'], 'paid' => ['shipped', 'refunded']] -
beforeWrite中先取旧状态：$old = $this->getOriginal('status')，再取新状态：$new = $this->getData('status') - 检查：
!isset($this->validTransitions[$old]) || !in_array($new, $this->validTransitions[$old])，不合法就抛InvalidArgumentException - 别用
allowField(true)->save(['status' => ...])，它不触发钩子，也拿不到旧值
批量更新订单状态时怎么不绕过钩子
运营后台批量关单、超时自动关单这类场景，Order::where(...)->update(...) 是最隐蔽的坑——它完全跳过模型层，beforeWrite 和 afterWrite 全不执行。
- 轻量级方案：先查 ID 列表（
Order::where(...)->column('id')），再分批查实体（Order::select($ids)），逐个调用$item->status = -1; $item->save(); - 性能敏感场景可拆两步：ID 查询走索引极快；实体加载按 50–100 条一批，避免内存爆炸
- 真到千万级清理，别假装“自动”，另起命令类（如
CloseTimeoutOrdersCommand），手动补全日志、库存释放、消息通知逻辑
状态码别硬编码在 if 里，更别散落在控制器
状态值（如 'pending'、'shipped'）必须集中定义，且禁止在控制器或服务类里出现字符串字面量比较。
- 在模型顶部定义常量：
const STATUS_PENDING = 'pending'; const STATUS_SHIPPED = 'shipped'; - 状态流转规则建议抽成独立配置文件（YAML/PHP 数组），由状态机类加载，而非写死在模型方法里
- 控制器里只该出现
$order->transitionTo(Order::STATUS_SHIPPED)这种语义化调用，不暴露底层字符串 - 用 PHPStan 配合正则规则禁用
->status =、setStat、setStatus等命名，从工具链卡住入口
最易被忽略的是并发安全：哪怕钩子逻辑完美，两个请求同时读到 pending 然后都改成 shipped，照样脏写。必须在 transitionTo 内部加 SELECT ... FOR UPDATE 行锁，且确保 id 是主键、status 字段有索引——否则锁表。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
