状态模式在PHP中应简化实现：用Order类+具体状态类+state属性即可，避免if判断和逻辑耦合；状态类需实现统一接口，专注合法性检查与状态变更，副作用交由领域服务或事件处理。
状态模式在 PHP 里不是必须用类库，自己写三个类就能跑起来
PHP 实现状态模式的关键不是套设计模式名词，而是把「对象当前行为随状态变化」这件事显式拆出来。别一上来就翻 State、Context 抽象类——多数业务里，一个 Order 对象 + 若干具体状态类（如 OrderPendingState、OrderShippedState）+ 一个 state 属性就足够了。
常见错误是把所有状态逻辑塞进主类，比如写一堆 if ($this->status === 'pending') { ... }，结果每次加个新状态都要改主类，还容易漏掉某处判断。
- 状态类只负责「自己能干什么」，不关心其他状态怎么切换
- 状态切换由 Context（比如
Order）统一触发，但实际变更操作放在状态类内部，比如$this->state->ship($this) - 避免在状态类里直接修改
$context->status = 'shipped'，应该通过 setter 或接口方法间接更新，否则后续加日志、校验、事件就难插手
状态类必须实现统一接口，否则 type-hint 和 IDE 支持会崩
PHP 没有接口强制约束时，很容易写成每个状态类方法名不一致，比如一个叫 handlePayment()，另一个叫 onPay()，结果调用方得不停判断类型再调方法，完全失去状态模式的意义。
正确做法是定义一个 OrderStateInterface，明确声明 canShip()、ship(Order $order)、cancel(Order $order) 这些方法。哪怕某个状态根本不支持发货，也得实现 ship()，只是抛出 InvalidStateException 或返回 false。
立即学习“PHP免费学习笔记（深入）”；
- 接口方法参数保持一致，尤其是传入的
$order要用具体类而非object，否则 PHPStan/PHPStorm 无法推导属性访问 - 不要为了“统一”而让接口包含所有可能动作，只放当前业务真实需要的状态响应点。比如售后流程和下单流程状态不同，别硬塞进同一个接口
- 如果状态行为特别简单（比如只有 2–3 行逻辑），其实用函数数组 + match 表达式更轻量：
match($order->status) { 'pending' => fn() => ..., 'shipped' => fn() => ... }，别强行上类
状态切换时最容易漏掉的是「副作用隔离」
比如用户点击发货，除了把订单设为 shipped，还要发通知、扣库存、生成物流单。这些不该藏在 OrderShippedState::ship() 里，否则测试难 mock，复用性差，还容易导致事务边界混乱。
正确的分层是：状态类只做「状态合法性检查 + 修改自身状态字段」，其他事交给领域服务或事件监听器。比如 OrderShippedState::ship() 内部只调 $order->setStatus('shipped')，然后触发 OrderShipped::dispatch($order)，由监听器去处理后续。
- 状态类里禁止调用 DB 查询、HTTP 请求、文件写入等外部依赖
- 如果状态切换涉及数据库更新，确保整个流程在同一个事务里，别让状态改了但库存没扣，造成不一致
- 注意 Doctrine 或 Laravel Eloquent 的 dirty tracking 可能被状态类绕过，手动调
$order->setDirty('status', true)或用touch()配合监听
Laravel 用户别直接往 Model 里塞状态逻辑
Laravel 的 Order Model 天然带 ORM 行为，很多人习惯在 ship() 方法里同时改状态、save、dispatch event，这会让状态逻辑和数据持久化耦合死。一旦要支持 API、队列、CLI 多入口，就只能复制粘贴逻辑。
更稳妥的方式是：Model 只负责数据映射，状态流转由单独的 OrderStateMachine 或 OrderTransitionService 管理，它接收 Order 实例，调用对应状态类的方法，再统一 save 并 dispatch 事件。
- 别用 Laravel 的
casts把状态转成枚举类（如OrderStatus::class），那只是值对象，不是状态模式 - 如果用了 spatie/laravel-model-status，它解决的是字段存取封装，不是状态行为隔离，两者定位不同，别混用
- 测试时，直接 new 一个状态类 + fake 的 Order，比 mock 整个 Eloquent Model 快得多，也更容易覆盖边界条件
状态模式真正的复杂点不在结构，而在「谁该决定能否切换」和「切换后谁来收尾」。这两个问题没想清楚前，先别急着建一堆 State 类。
