4. 支付订单生命周期全景
支付订单不是一张静态的数据库记录，而是一个随时间推进、受多方事件驱动、在有限状态之间迁移的“活对象”。理解支付订单的生命周期，本质上是理解一笔交易从意图产生到资金与权益最终落定的全过程。本章将支付订单划分为八个核心阶段，并说明每个阶段的进入条件、关键动作与退出路径。
一、核心原理：为什么需要阶段划分
支付订单的状态机之所以必须显式划分阶段，是因为支付涉及三个不同步的“时钟”：用户操作时钟（点击、跳转、确认）、渠道处理时钟（银行、第三方支付网关的异步回调）、平台账务时钟（记账、分账、结算）。三者节奏不一致，若没有清晰的阶段边界，就会出现“用户以为没付、渠道已扣款、平台未记账”的经典不一致问题。
阶段划分的核心价值有三点：一是明确每个状态下允许的操作（如待支付可取消，支付中不可重复发起）；二是定义状态迁移的触发源（用户行为、渠道回调、定时任务、人工干预）；三是为对账与补偿提供锚点，每个阶段都有对应的可核对数据。
二、八阶段全景与状态迁移
下面用一张状态迁移图展示支付订单从创建到完结的完整路径。图中每个节点是一个阶段，箭头上的文字是触发迁移的事件。
八个阶段的定义如下：
| 阶段 | 状态码 | 进入条件 | 允许操作 | 退出路径 |
|---|---|---|---|---|
| 创建 | CREATED | 用户提交订单，生成支付单号 | 查询、修改金额（未锁定前） | 进入待支付 |
| 待支付 | PENDING | 订单已锁定，等待用户付款 | 发起支付、取消、超时关单 | 支付中 / 关单 |
| 支付中 | PAYING | 已向渠道发起扣款请求 | 查询渠道结果、禁止重复发起 | 成功 / 失败 |
| 支付成功 | SUCCESS | 渠道回调确认扣款成功 | 发货、开票、发起退款 | 退款 / 完结 |
| 支付失败 | FAILED | 渠道返回失败或超时未确认 | 重试、换渠道、关闭 | 待支付 / 关单 |
| 关单 | CLOSED | 超时未付或用户主动取消 | 查询、重新下单 | 完结 |
| 退款 | REFUND | 用户申请或平台发起退款 | 查询退款进度、部分退款 | 完结 |
| 完结 | FINISHED | 资金与权益均已落定 | 仅查询、归档 | 终态 |
三、典型场景：一次外卖支付的完整旅程
以用户点一份外卖为例，观察订单如何穿越各阶段：
- 创建：用户点击“提交订单”，系统生成支付单号
PAY20240520120001，金额 38.50 元，状态 CREATED。 - 待支付：订单锁定库存与优惠券，状态变为 PENDING，同时启动 15 分钟超时定时器。
- 支付中：用户选择微信支付，系统调用渠道下单接口，状态置为 PAYING，并记录渠道流水号。
- 支付成功：微信异步回调通知扣款成功，系统验签后更新为 SUCCESS，触发商家接单与骑手调度。
- 退款：用户发现地址填错，商家未接单前申请退款，状态进入 REFUND。
- 完结：退款到账后，订单归档为 FINISHED，库存与优惠券回滚完成。
四、误区与复盘：三个高频踩坑点
误区一：把“支付中”当成“成功”处理。 某些渠道在同步返回中只表示“请求已受理”，并不代表扣款成功。若此时直接发货，一旦后续回调失败，平台将承担资损。正确做法是：同步返回仅用于展示“处理中”，最终状态以异步回调或主动查询为准。
误区二：关单与退款混为一谈。 关单针对的是“未支付”的订单，资金从未变动；退款针对的是“已支付”的订单，资金需要原路或指定路径退回。两者在账务处理、渠道接口、对账逻辑上完全不同，不能共用同一套状态迁移。
误区三：忽略超时关单的幂等性。 定时任务关单与用户主动取消可能同时发生，若没有幂等控制，会出现重复关单、库存重复回滚。建议在关单操作上加分布式锁或状态条件更新：
UPDATE pay_order
SET status = 'CLOSED', close_time = NOW()
WHERE pay_no = 'PAY20240520120001'
AND status = 'PENDING';只有受影响行数为 1 时才执行后续的库存回滚，否则说明已被其他路径处理，直接跳过。