抽象订单类封装状态持有与变更机制，委托具体状态类处理行为逻辑，子类专注业务扩展，确保状态流转清晰可控且可维护。
在 Java 抽象类中结合状态模式管理订单生命周期，核心是：用抽象类定义订单的通用结构和受保护的状态变更机制，把具体状态行为委托给独立的状态类，避免在抽象类中堆积 if/else 或 switch 分支。
抽象订单类封装状态持有与基础操作
抽象类不直接实现状态逻辑，而是持有一个可变的 State 引用，并提供受保护的 changeState(State newState) 方法供子类或状态类调用。它定义订单共有的字段（如 orderId、createTime）和模板方法（如 pay()、ship()、cancel()），这些方法只做校验和委托，不写具体流转规则。
- 状态引用声明为
protected State currentState，允许子类和状态类安全访问 - 每个业务动作（如
pay()）先检查当前状态是否允许该操作，再调用currentState.handlePay(this) - 禁止外部直接修改
currentState，所有变更必须通过changeState()
状态接口与具体状态类分离行为逻辑
定义一个 State 接口（或抽象类），声明所有订单动作的处理方法（handlePay(Order order)、handleShip(Order order) 等）。每个具体状态（如 CreatedState、PaidState、ShippedState）实现该接口，只响应自己允许的操作，并在必要时触发状态切换。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
CreatedState.handlePay()执行支付逻辑后调用order.changeState(new PaidState()) -
PaidState.handlePay()可抛出异常或静默忽略，体现“已支付不可重复支付” - 状态类不持有订单数据，只通过参数接收
Order实例进行操作
子类聚焦业务扩展而非状态判断
具体订单类型（如 VipOrder、InternationalOrder）继承抽象订单类，只需覆盖特定钩子方法（如 onPaid()、onShipped()），用于添加专属逻辑（如发短信、调用物流接口）。状态流转仍由状态类控制，子类不参与决策。
立即学习“Java免费学习笔记（深入）”；
- 避免在子类中重写
pay()去判断能否支付——那是状态类的职责 - 若某类订单在发货前需额外审核，可在
PaidState.handleShip()中调用order.isVip() ? order.approveBeforeShip() : ... - 状态类可通过
instanceof区分订单类型，但更推荐依赖抽象方法（如order.getApprovalPolicy()）
初始化与状态一致性保障
抽象订单类的构造器应强制设置初始状态（如 changeState(new CreatedState())），确保每个实例从创建起就处于明确状态。同时，将 currentState 设为 final 不可行（因需变更），改用私有字段 + 严格封装，配合单元测试覆盖非法状态迁移路径（如从 ShippedState 调用 cancel()）。
- 在
changeState()中加入日志或事件发布，便于追踪状态变迁 - 考虑用枚举定义合法状态集合，在状态类构造时校验，防止无效状态注入
- 数据库持久化时，只存状态标识符（如字符串
"PAID"），加载时根据标识重建对应状态对象
