订单状态流转采用“主表状态字段+日志表”双表结构，主表orders用数字status存当前状态，日志表order_status_logs记录每次变更详情并建联合索引，状态更新须事务保障、前置校验与行锁，并通过FSM配置表约束合法流转路径。
订单状态流转的核心是用数据库准确记录订单生命周期中的关键节点，MySQL 中通过状态字段 + 状态变更日志双表结构最稳妥、可追溯、易排查。
订单主表：只存当前有效状态
在 orders 表中设一个 status 字段（如 TINYINT 或 ENUM），仅表示订单当前所处的最新状态，例如：
- 0 → 待支付
- 1 → 已支付
- 2 → 已发货
- 3 → 已签收
- -1 → 已取消
- -2 → 已退款
不建议用字符串（如 'paid'、'shipped'）直接存，除非业务极简单；优先用数字+字典表或代码常量映射，便于索引和查询优化。
状态日志表：每次变更都留痕
新建 order_status_logs 表，强制记录每一次状态更新，字段至少包括：
- order_id（关联主表）
- from_status（变更前状态）
- to_status（变更后状态）
- operator_type（谁触发的：user / system / admin）
- operator_id（操作人ID，如用户ID或管理员ID）
- created_at（时间戳，带毫秒更佳）
- remark（可选，如“超时未支付自动关闭”、“客服手动退款”）
这个表要建联合索引：(order_id, created_at)，方便按单查全流程；也可加 (to_status, created_at) 支持统计某类状态的分布。
状态流转必须走事务 + 前置校验
不能直接 UPDATE orders SET status = 2 WHERE id = 123；必须封装成原子操作：
- 查当前 status 是否允许跳转到目标状态（比如“已签收”不能从“待支付”直接来）
- 开启事务，先 INSERT 日志，再 UPDATE 主表 status
- 任一失败则回滚，保证主表和日志一致
- 加行锁（SELECT ... FOR UPDATE）防并发重复提交
例如：用户支付回调到达时，需校验订单是否为“待支付”，且金额匹配，再执行发货前的状态变更流程。
避免状态爆炸，用有限状态机（FSM）约束
把订单流程抽象成一张有向图，每个状态只允许走向预定义的下一状态。可用配置表 order_status_transitions 管理规则：
- from_status | to_status | allowed（布尔）
- 0 → 1 ✔️（待支付→已支付）
- 0 → -1 ✔️（待支付→已取消）
- 1 → 0 ❌（已支付不能退回待支付）
业务代码在变更前查这张表，不满足则拒绝，比硬编码 if-else 更灵活、易维护。
