状态模式通过为每种订单状态创建独立类（如PendingPaymentState、ShippedState），实现状态行为内聚：每个类实现OrderState接口，仅定义自身合法操作，并在执行后主动切换订单状态，使流转逻辑分散到各状态类中，新增状态只需添加类而无需修改原有代码。
用状态模式把订单状态流转逻辑理清楚，核心是让每个状态自己决定“能做什么”和“能变成什么”，而不是在一堆if-else或switch里硬编码所有跳转规则。
把每个状态变成独立的类
别再用字符串或枚举值代表状态，而是为“待支付”“已发货”“已完成”“已取消”等每种状态创建一个具体类，比如PendingPaymentState、ShippedState。这些类统一实现同一个接口（如OrderState），接口里定义通用行为：pay()、ship()、cancel()、complete()等。每个类只实现自己合法的操作——比如ShippedState的cancel()可以抛异常或返回失败，而PendingPaymentState的ship()直接不支持。
让订单持有当前状态的引用
订单对象（Order）不再保存int或String类型的状态字段，而是持有一个OrderState类型的成员变量。所有状态变更都通过调用状态对象的方法来触发，比如order.pay()内部会委托给当前状态的pay()方法；该方法执行完业务逻辑（如扣减库存、生成支付单）后，主动把订单的state字段替换成下一个状态对象（例如从PendingPaymentState切换到PaidState）。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
状态迁移逻辑内聚在状态类内部
谁决定“支付成功后进入什么状态”？不是订单，也不是Service层，而是PendingPaymentState自己。它在pay()里做完校验和业务处理后，直接调用order.setState(new PaidState())。这样，整个流转路径被分散到各个状态类中，新增状态只需加一个类+改少量委托，不会动到其他状态的代码。常见迁移场景如：
立即学习“Java免费学习笔记（深入）”；
- 用户取消待支付订单 → PendingPaymentState.cancel() → 切换为CancelledState
- 管理员强制发货 → PaidState.ship() → 切换为ShippedState
- 物流签收回调 → ShippedState.confirmReceipt() → 切换为CompletedState
配合状态机工具可进一步可视化和管控
基础状态模式已足够清晰，若需审计、监控或动态配置流转规则，可引入轻量级状态机框架（如Spring State Machine或Squirrel）。它们基于同样思想，但提供状态图定义（XML/JavaConfig）、事件日志、条件判断钩子等功能。关键仍是：状态行为归属状态本身，而非散落在各处的条件分支。
