ThinkPHP模型中需通过beforeWrite或afterWrite钩子实现状态机，而非裸赋值或where-update；前者校验状态合法性，后者触发通知等副作用，确保业务操作与状态推进强绑定且事务安全。
ThinkPHP 模型里怎么用 save() 触发状态自动推进
状态机不是 ThinkPHP 原生能力，得靠模型事件或重写 save() 实现。直接在控制器里硬编码状态跳转，后续加个“取消订单”或“超时关单”就容易漏逻辑、难维护。
推荐做法：把状态流转规则收口到模型的 beforeWrite 或 afterWrite 钩子中，配合字段值变化做判断。
- 别在控制器里写
$order->status = 2; $order->save();这种裸赋值——它绕过了所有校验和副作用 - 用
$order->allowField(true)->save(['status' => 2])也不行，allowField不触发钩子，且无法感知旧值 - 正确姿势是先查出原记录（或用
getOriginal()），再比对status是否变化，再决定是否执行下游动作（如发消息、改库存）
为什么不能只靠数据库触发器或定时任务推进订单状态
数据库触发器看不到业务上下文（比如谁操作的、来自哪个渠道），也难处理跨表逻辑（如扣减商品库存需查 product 表）；定时任务有延迟，且无法响应即时操作（如用户付款成功那一刻就要改状态+通知）。
状态推进必须和业务操作强绑定，而 ThinkPHP 的模型生命周期钩子刚好卡在这个位置。
立即学习“PHP免费学习笔记（深入）”；
-
beforeWrite可拦截并修改待写入数据，适合做状态合法性校验（比如不允许从“已发货”直接跳回“待支付”） -
afterWrite更适合发通知、调接口、更新关联表——此时主键已确定，ID 可靠 - 注意：如果用了事务，钩子也在事务内，失败会一起回滚；但第三方服务调用（如微信回调通知）得单独处理幂等，不能放钩子里直接发
常见错误：用 where()->update() 绕过模型导致状态机失效
这是最隐蔽的坑。比如后台运营要批量关闭超时订单，写了 Order::where('status', 1)->where('create_time', 'update(['status' => -1]) —— 看似高效，实则完全跳过了模型层，beforeWrite/afterWrite 全不触发，库存没释放、日志没留痕、消息没发。
- 批量操作也要走模型：用
Order::select($ids)查出对象数组，再 foreach 调用$item->status = -1; $item->save(); - 性能敏感场景可拆成两步：先查 ID 列表（轻量），再分批查实体并更新（可控）
- 实在不能走模型（比如千万级数据清理），那就另起一个专用命令类，手动补全状态变更的副作用逻辑，别假装它“自动”了
状态定义和流转规则怎么组织才不容易乱
别把状态码写死在代码里（if ($status == 3) { ... }），也别塞进配置文件靠 if-else 匹配——改个流程就得翻好几个地方。
- 在模型里定义常量：
const STATUS_PENDING = 1;、const STATUS_PAID = 2;，所有地方统一引用 - 用二维数组声明合法转移：
protected $validTransitions = [self::STATUS_PENDING => [self::STATUS_PAID, self::STATUS_CLOSED]]; - 在
beforeWrite里检查：if (!in_array($this->status, $this->validTransitions[$originalStatus] ?? [])) { throw new Exception('非法状态跳转'); } - 流转动作本身（如“支付成功后减库存”）建议抽成独立方法：
$this->onPaid();，便于单元测试和复用
状态机真正的复杂点不在代码怎么写，而在“谁有权发起哪次跳转”和“跳转前后必须保证哪些数据一致性”。这些规则一旦散落在各处，后面加个“仅限客服操作”的限制，就只能全局 grep 了。
