订单状态迁移不能用if-else堆出来，因其本质是带分支、可回退、需审计、易并发冲突的网状关系；直接赋值会导致校验散落、扩展困难、并发脏写、日志缺失。
订单状态迁移为什么不能用 if-else 堆出来
因为订单状态流转不是线性链条，而是带条件分支、可回退、需审计、可能并发修改的网状关系。直接用
会导致：状态校验散落各处、新增状态要改七八个文件、并发下单时两个请求同时把“待支付”改成“已发货”、日志里根本看不出谁触发了这次变更。
用状态模式组织状态类，但别搞抽象工厂套娃
核心是让每个状态自己决定“能迁移到哪些状态”以及“迁移前要检查什么”，而不是靠外部判断。关键点不是设计多优雅的继承体系，而是控制住状态变更入口：
所有状态变更必须走
方法，禁止直接赋值
每个具体状态类（如
、
）实现
和
状态类不持有业务逻辑（比如发短信、扣库存），只做状态合法性校验；实际动作由独立的服务类触发
示例：
返回
，但
可能返回
或检查是否超时——逻辑收束在状态内部，不污染订单主类。
并发场景下状态变更必须加数据库行锁
哪怕状态类逻辑再严谨，两个 PHP 进程同时读到“待支付”，又同时调用
，照样会出问题。解决方式不是加 Redis 分布式锁，而是利用数据库事务+行锁：
立即学习
“
PHP免费学习笔记（深入）
”；
PHP 8.5.5
PHP 8.5.5 是 PHP 8.5 分支的维护更新版本。该版本延续了“小步快跑”的迭代逻辑，通过深度错误修复、底层性能微调以及安全加固，旨在为开发者提供一个更健壮、更高效的运行环境。该版本严格遵守语义化版本规范，不包含破坏性变更。
下载
在
中开启事务
执行
锁住该订单记录（例如
）
如果查询没返回结果，说明状态已被其他请求改过，抛出
更新状态后提交事务
注意：MySQL 的
在非唯一索引或无索引字段上会锁表，务必确保
是主键，且
字段有索引。
状态迁移日志必须记录 from/to/trigger/reason
运维查问题时最常问：“这个订单怎么从‘已发货’变成‘已完成’的？谁操作的？有没有填退款单号？” 所以日志不是记“状态变了”，而是结构化存四要素：
：变更前状态（如
）
：变更后状态（如
）
：触发方（如
、
、
）
：补充说明（如
、
）
这些字段要进数据库单独的
表，别只写在 Laravel Log 或 Monolog 里——日志文件没法关联查询，也留不住太久。
状态模式本身不难，难的是把校验、锁、日志、回滚这四件事和状态类真正咬合在一起。很多人卡在“状态类写完了，但没人调用它”，或者“锁加了，日志却漏了触发源”。真正跑得稳的系统，状态迁移从来不是单点技术问题。
if ($order->status === 'paid') { $order->status = 'shipped'; }Order::transitionTo($newState)$order->statusPaidStateShippedStatecanTransitionTo(string $target): boolonTransitionTo(Order $order, string $from): voidPaidState::canTransitionTo('shipped')truePaidState::canTransitionTo('cancelled')falsetransitionTo('shipped')transitionTo()SELECT ... FOR UPDATESELECT * FROM orders WHERE id = ? AND status = 'paid' FOR UPDATEInvalidStateExceptionFOR UPDATEidstatusfrom'shipped'to'completed'trigger'courier_webhook''admin_manual''timeout_job'reason'tracking number: SF123456789''auto-complete after 7 days'order_status_logs