订单状态应使用枚举定义，如OrderStatus包含CREATED、PAYING等状态并携带业务属性；状态流转需白名单校验；更新须事务+乐观锁保障原子性；每次变更须记录日志。
订单状态应使用枚举定义，避免字符串硬编码
状态值必须集中管理，推荐用 enum 实现，比如 OrderStatus 枚举包含 CREATED、PAYING、PAID、SHIPPED、DELIVERED、CLOSED、CANCELLED 等。每个枚举项可自带业务属性，如是否可退款、是否终态、是否允许人工干预等。
好处是编译期校验、IDE自动提示、避免拼写错误，也方便后续扩展状态行为（比如通过接口或方法绑定状态专属逻辑）。
状态流转需明确规则，用状态机或白名单控制合法跳转
不是所有状态之间都能互相切换。例如：
- CREATED → PAYING 允许，但 CREATED → SHIPPED 不允许；
- PAID → SHIPPED 合理，但 PAID → CANCELLED 可能受限（比如超时才允许）；
- DELIVERED 是终态，不能再变更为其他状态。
建议方式：
- 定义一个 TransitionRule 映射表（如 Map），声明每个状态的合法下一状态；
- 在状态更新方法中强制校验，不满足则抛出 IllegalStateException 或自定义异常；
- 复杂场景可用轻量级状态机框架（如 Spring State Machine），但多数业务系统用白名单校验已足够清晰可控。
状态变更必须原子化，结合数据库事务与乐观锁保障一致性
订单状态更新常伴随其他字段修改（如付款时间、发货单号），必须在同一个数据库事务中完成。同时要防止并发重复提交导致状态错乱，例如两次点击“确认发货”造成重复发货。
关键做法：
- 使用数据库行级锁（如 SELECT ... FOR UPDATE）或应用层分布式锁（适合高并发微服务）；
- 更常用的是乐观锁：订单表加 version 字段，更新时带上原 version 值，SQL 中增加 WHERE version = ?，更新成功才递增 version；
- 更新语句示例：UPDATE order SET status = ?, ship_no = ?, version = version + 1 WHERE id = ? AND status = ? AND version = ?。
记录状态变更日志，便于追溯和对账
每次状态变更都应写入独立的日志表（如 order_status_log），至少包含：
- 订单 ID
- 原状态、目标状态
- 操作人（用户ID / 系统标识，如 “pay-service”）
- 触发方式（如 “user_submit”, “timeout_close”, “manual_override”）
- 时间戳、备注（可选）
这不仅是排查问题的依据，也是后续做状态漏斗分析、自动化监控（如“下单后2小时未支付”告警）、审计合规的基础。
立即学习“Java免费学习笔记（深入）”；
基本上就这些。核心是：枚举管住取值，规则卡住流转，事务+锁守住一致性，日志留下证据。不复杂但容易忽略细节。
