【day17】订单状态机设计与变迁规则

订单状态机用于管理订单生命周期中的状态变迁，确保流程合理且符合业务规则。以下是典型电商订单状态机设计及变迁规则的详细说明：

---

一、核心状态定义

1. 待支付
   • 用户提交订单后，尚未完成支付的初始状态
2. 已支付
   • 用户支付成功，系统确认收款
3. 待发货
   • 商家准备商品，等待物流交接
4. 已发货
   • 商品已交物流，运输中
5. 已签收
   • 用户确认收到商品
6. 已完成
   • 订单正常结束（如自动确认签收后）
7. 已取消
   • 订单被终止（细分类型：用户取消、系统超时取消、商家取消）
8. 退款中
   • 用户发起退款/退货申请，处理中
9. 已退款
   • 退款流程完成，资金退回用户

---

二、状态变迁规则

1. 正向流程

• 待支付 → 已支付
  条件：用户支付成功（支付系统回调确认）
  动作：生成支付凭证，通知商家备货。

• 已支付 → 待发货
  条件：商家确认库存充足，准备发货。
  动作：分配库存，生成物流单号。

• 待发货 → 已发货
  条件：商家录入物流信息并提交。
  动作：同步物流信息，通知用户。

• 已发货 → 已签收
  条件：

  • 用户主动确认收货，或
  • 系统根据物流信息自动签收（如物流显示签收且超时无异议）。

• 已签收 → 已完成
  条件：

  • 签收后无退款申请（如7天后自动完成）。

---

2. 逆向流程

• 取消订单

  • 待支付 → 已取消
    条件：用户主动取消 或 支付超时（如30分钟未支付）。
  • 已支付 → 已取消
    条件：商家同意取消（如未发货时用户申请）。
    动作：释放库存，触发退款。

• 退款流程

  • 已支付/待发货/已发货 → 退款中
    条件：用户提交退款申请，商家/系统审核通过。
  • 退款中 → 已退款
    条件：退款处理完成（需与支付渠道交互）。
  • 退款中 → 原状态
    条件：退款申请被驳回。

---

3. 异常处理

• 物流异常

  • 已发货 → 待发货（重新发货）
  • 已发货 → 已取消（商品丢失，全额退款）。

• 部分履约

  • 拆分为子订单，独立管理状态（如部分发货、部分退款）。

---

三、规则约束

1. 权限控制

   • 用户仅可操作：取消待支付订单、申请退款（在允许状态下）。
   • 商家/后台可操作：发货、取消订单、处理退款。
   • 系统自动操作：超时取消、自动签收、自动完成订单。

2. 状态不可逆

   • 已完成/已取消的订单不可再修改（除非人工干预）。

3. 审计日志

   • 记录所有状态变更的时间、操作者、原因，便于追溯。

---

四、扩展性设计

• 自定义状态：支持根据业务需求（如预售、团购）添加状态（如“待成团”）。
• 事件驱动：通过消息队列触发状态变更（如支付成功事件、物流回调事件）。
• 状态机引擎：使用工具（如Spring StateMachine）管理复杂规则。

---

五、示例流程图

待支付 →（支付）→ 已支付 →（备货）→ 待发货 →（发货）→ 已发货  
已发货 →（签收）→ 已签收 →（超时）→ 已完成  
已支付 →（取消）→ 已取消  
已支付/待发货/已发货 →（退款申请）→ 退款中 →（处理）→ 已退款/原状态

---

通过合理设计状态机，可确保订单流程清晰、减少人工干预，并提升用户体验与系统可靠性。实际需结合业务场景（如实物、虚拟商品、服务类订单）调整细节。