业务背景与设计目标

在数字化租赁电商业务中，用户下单并签约后，系统已完成芝麻信用免押评估、预授权资金冻结与电子合同盖章，且商家/门店仓库已在备货、质检贴膜与打包。若允许用户直接秒级取消订单，将导致商家备货损耗、资方资金占用以及平台履约考核指标的异常波动。

EBAOZU V4 设计了 “申请 ＞ 审核” 二段式取消机制，并针对已支付待发货订单创新实现了 “状态 3（is_user_del=3）履约退款异步逆向链路”。既保障了承租人的退款权益，又兼顾了商户端的发货履约统计口径。

---

状态机与底层字段定义

核心状态字段位于 eb_store_order.is_user_del：

字段值	状态名称	说明
0	正常状态	订单正常流转中（待发货、在租履约中、或正常交易完成）
1	已取消	订单已彻底取消关闭，库存释放，首期款原路退回
2	取消审核中	用户已支付且申请取消，等待后台/门店客服 2 小时内审核
3	履约退款处理中	商家选择路线 B，异步队列正在执行“核销完结 + 自动退款”逆向链

状态流转拓扑图

用户点击取消（租赁单, is_lease=1 且 status<1）
   │
   ├─► [未支付订单] ───────────────► 直接取消（释放库存，不进审核）
   │
   └─► [已支付待发货] ─────────────► 【is_user_del = 2 取消审核中】
                                        │
                                        ├─► 客服同意取消 ────────────► 【is_user_del = 1 已取消】（执行 cancelLeaseOrder 全链路退款与解约）
                                        ├─► 用户主动撤销 ────────────► 【is_user_del = 0 正常】（恢复待发货）
                                        ├─► 2小时超时未处理 ─────────► 自动同意取消 ──► 【is_user_del = 1 已取消】
                                        │
                                        ├─► 商家拒绝: 路线 A (handle_type=1) ──► 【is_user_del = 0 正常】（恢复待发货，发送站内信）
                                        │
                                        └─► 商家拒绝: 路线 B (handle_type=2) ──► 【is_user_del = 3 履约退款处理中】
                                                                                    │ (异步任务 LeaseRejectFulfillJob)
                                                                                    ├─ 1. 自动转为自提模式
                                                                                    ├─ 2. 系统静默核销收货
                                                                                    ├─ 3. 完结订单 (status=6 交易完成)
                                                                                    ├─ 4. 解冻预授权与代扣协议
                                                                                    └─ 5. 原路退还已付首期租金
                                                                                    │
                                                                                    ▼
                                                                             【is_user_del = 0, status = 6 完结】

---

双分支处置路线深度实现

路线 A：拒绝并恢复 (handle_type = 1)

• 接口：POST /adminapi/order/cancel_apply_reject/:id
• 处理逻辑：
  1. 校验 is_user_del == 2；
  2. 原子更新 is_user_del = 0；
  3. 写入 eb_store_order_status 操作流水（cancel_apply_rejected）；
  4. 向承租人发送站内信/短信通知：“您的订单取消申请已被拒绝，订单已恢复正常备货发货流程”。

---

路线 B：拒绝并完结退款 (handle_type = 2 / 状态 3 链路)

该路线是承信租 V4 独创的柔性逆向解决方案，核心由 LeaseRejectFulfillJob 队列任务异步驱动：

// app/jobs/order/LeaseRejectFulfillJob.php
public function doJob($orderId)
{
    // 1. 获取分布式锁，防止并发重入
    // 2. 检查订单状态是否处于 is_user_del = 3
    // 3. 将 shipping_type 修改为 2 (门店自提)
    // 4. 生成虚拟自提核销记录并调用核销收货接口 (StoreOrderServices::takeOrder)
    // 5. 调用支付宝/微信解冻预授权押金与解除周期扣款协议
    // 6. 调用退款服务原路返还用户全部已实付租金 (StoreOrderRefundServices::refund)
    // 7. 更新订单终态 status = 6 (交易完成), is_user_del = 0
}

路线 B 的核心优势

1. 保障发货与履约率口径：订单最终以「交易完成」状态归档，商户平台履约率不受取消订单拖累；
2. 资金与权限安全闭环：用户无需担心资金滞留，所有实付款原路原账返回，支付宝预授权额度全额释放；
3. 异步解耦与异常重试：第三方接口（支付宝解冻/微信退款）发生网络抖动时，队列具备 3 次指数退避重试机制，若重试耗尽则停留在状态 3 并触发钉钉/企微运维告警，人工介入排查。

---

并发安全与幂等保护

1. 在途支付单强制关闭：用户提交取消申请瞬间，系统立即调用第三方支付接口关闭在途支付二维码/拉起单，防止用户在审核期间完成支付造成账实冲突。
2. 分布式 Redis 锁机制：在用户撤销申请、管理员同意/拒绝、以及 2 小时定时任务自动同意时，均使用 Redis::lock('order_cancel_'.$orderId, 10) 进行强互斥，杜绝并发重复退款。