企业级订单生命周期应通过枚举类集中管控状态流转规则、行为约束与业务语义，核心在于状态不可篡改、流转可校验、扩展可预期；枚举需包含状态码、中文描述、终态标识、允许的下一状态等元信息，并配合状态机实现校验与事件驱动，支持多场景差异化模型及与持久层、外部系统协同一致。
在企业级开发中，用枚举类管理订单生命周期，核心是把状态流转规则、行为约束和业务语义集中管控，避免散落在 if-else 或魔法字符串里。关键不在“定义几个值”，而在“让状态不可篡改、流转可校验、扩展可预期”。
用枚举封装状态语义与合法性边界
订单状态不是简单罗列，而是带业务含义的有限集合。比如：
- PENDING_PAYMENT：已创建未支付，允许取消、支付，不允许发货；
- PAID：支付成功，允许发货、申请退款，不允许再次支付；
- SHIPPED：已发货，允许签收、售后，不允许取消或退款（需走退货流程）。
枚举字段应包含：
- 状态码（如 "PENDING_PAYMENT"）用于数据库存储和序列化；
- 中文描述（如 "待支付"）用于前端展示或日志；
- 是否终态（isTerminal()）、是否可逆（isReversible()）等元信息；
- 允许的下一个状态列表（allowedNextStates()），为状态机提供基础支撑。
配合状态机实现流转校验与事件驱动
单纯枚举不能阻止非法变更，需结合轻量状态机（如 Spring State Machine 或自研状态流转器）。关键点：
- 所有状态更新必须通过 order.changeState(NEW_STATE) 统一入口；
- changeState 内部调用枚举的 allowedNextStates() 判断是否允许跳转；
- 拒绝非法操作并抛出明确异常（如 InvalidOrderStateException），不静默失败；
- 状态变更后自动触发事件（如 OrderPaidEvent），解耦后续动作（发短信、扣库存、更新搜索索引）。
例如：从 PAID 尝试直接跳到 DELIVERED（跳过 SHIPPED），会被枚举 + 状态机双重拦截。
支持多场景差异化状态模型
不同业务线（如电商主站、跨境、B2B）可能有不同生命周期。不要硬塞进一个大枚举，而是：
- 定义顶层接口 OrderStatus，声明通用方法（getCode(), getDescription()）；
- 按业务域拆分子枚举：ECommerceOrderStatus、CrossBorderOrderStatus；
- 用工厂或策略模式根据订单类型动态加载对应状态枚举和流转规则；
- 共享部分状态（如 CANCELLED）可通过接口默认方法或抽象基类复用逻辑。
与持久层和外部系统协同一致
枚举必须和数据库、RPC 接口、消息体对齐：
- 数据库字段类型设为 varchar(32)，存枚举的 code（非序号），避免新增状态导致数值错位；
- MyBatis / JPA 映射时，用 TypeHandler 或 AttributeConverter 自动转换枚举 ↔ 字符串；
- 对外 API 响应中，status 字段返回 code（便于下游解析），同时可选附带 label 字段供前端展示；
- 消息队列中传递状态变更时，只传 code 和订单 ID，确保上下游无需同步枚举类也能消费。
不复杂但容易忽略：枚举类要加 @Immutable 注解（或文档注明不可继承）、所有字段 final、构造私有、禁止暴露 setter。状态一旦发布，只允许追加，不得修改已有项的含义或删除——这是契约稳定性的底线。
