4. 支付订单状态定义：待支付、支付中、支付成功、支付失败、退款中、已退款等状态枚举

支付订单状态是支付系统状态机的核心数据载体。状态定义是否清晰、边界是否明确，直接决定了后续幂等校验、异常恢复、对账清算的工程复杂度。本章从枚举设计、状态流转约束、数据库持久化三个维度，给出可落地的支付订单状态定义方案。

4.1 核心状态枚举与语义

支付订单状态采用有限状态机（FSM）模型，每个状态对应一个明确的业务阶段。以下为生产环境通用的六状态枚举定义：

枚举值 状态码 业务语义 允许操作
待支付 PENDING 订单已创建，等待用户发起支付请求 支付、取消
支付中 PROCESSING 支付请求已提交渠道，等待异步结果 查询、超时关闭
支付成功 SUCCESS 渠道明确返回成功，资金已划拨 退款、查询
支付失败 FAILED 渠道明确返回失败，资金未划拨 重试支付、关闭
退款中 REFUNDING 退款请求已提交渠道，等待异步结果 查询退款状态
已退款 REFUNDED 退款成功，资金已原路返回 查询
工程建议：状态码使用大写英文单词，避免使用数字编码（如 0/1/2）。数字编码在数据库查询时语义不直观，且扩展时容易与历史值冲突。英文枚举在代码审查和日志排查时可读性更高。

4.2 状态流转约束与非法路径

并非所有状态之间都可以直接跳转。状态机必须定义合法的转换边，防止因并发或异常导致状态错乱。以下为支付订单的完整状态转换图：

支付订单状态机流转图 待支付 支付中 支付成功 支付失败 退款中 已退款 发起支付 异步通知成功 异步通知失败 发起退款 退款成功 重试支付（回到待支付） ⚠ 非法路径（禁止转换） • 待支付 → 支付成功（跳过支付中，无渠道确认） • 支付失败 → 支付成功（状态已终态，不可逆转） • 已退款 → 任何状态（终态不可逆）
常见陷阱：部分设计将“支付失败”直接跳转到“支付成功”，这是严重错误。支付失败必须经过“待支付”或“支付中”重新发起，才能再次进入成功路径。跳过中间状态会导致资金对账永远无法对齐。

4.3 状态枚举的数据库持久化方案

在 PostgreSQL 中，状态枚举推荐使用 VARCHAR 类型存储枚举名称，配合 CHECK 约束保证数据完整性。以下为建表 DDL：

CREATE TABLE payment_order (
    order_id        BIGSERIAL       PRIMARY KEY,
    order_no        VARCHAR(64)     NOT NULL UNIQUE,
    amount          NUMERIC(12,2)   NOT NULL,
    currency        VARCHAR(3)      NOT NULL DEFAULT 'CNY',
    status          VARCHAR(20)     NOT NULL DEFAULT 'PENDING',
    created_at      TIMESTAMPTZ     NOT NULL DEFAULT NOW(),
    updated_at      TIMESTAMPTZ     NOT NULL DEFAULT NOW(),
    version         INTEGER         NOT NULL DEFAULT 1,

    -- 状态枚举约束
    CONSTRAINT chk_payment_order_status CHECK (
        status IN ('PENDING','PROCESSING','SUCCESS','FAILED','REFUNDING','REFUNDED')
    ),

    -- 金额非负约束
    CONSTRAINT chk_amount_positive CHECK (amount >= 0)
);

-- 状态索引：加速按状态查询待处理订单
CREATE INDEX idx_payment_order_status ON payment_order(status)
    WHERE status IN ('PENDING','PROCESSING','REFUNDING');
设计要点：
  • VARCHAR 优于 INTEGER：枚举名称自描述，无需额外映射表，日志和排查时直接可见。
  • CHECK 约束：数据库层强制状态值合法，防止代码 bug 写入脏数据。
  • 部分索引：只索引待处理状态，减少索引体积，提升扫描效率。
  • version 字段：用于乐观锁，防止并发更新导致状态覆盖。

4.4 状态变更的幂等更新 SQL

支付系统的高并发场景下，同一订单可能同时收到多个渠道回调。状态更新必须使用带条件判断的幂等 SQL，避免状态回退：

-- 支付成功回调：仅当当前状态为 PROCESSING 时才更新
UPDATE payment_order
SET status = 'SUCCESS',
    updated_at = NOW(),
    version = version + 1
WHERE order_no = '20250315001'
  AND status = 'PROCESSING'
  AND version = 1;   -- 乐观锁版本号

-- 如果影响行数为 0，说明状态已变更或版本不匹配，需走异常处理流程
幂等校验核心：状态更新 SQL 中同时携带 status 和 version 两个条件。前者防止状态回退（如从 SUCCESS 被改回 PROCESSING），后者防止并发覆盖。两条防线缺一不可。

4.5 状态枚举与业务操作的映射矩阵

为方便代码实现和测试用例设计，以下矩阵列出了每个状态下允许的业务操作：

操作 \ 当前状态 待支付 支付中 支付成功 支付失败 退款中 已退款
发起支付 ✅ ❌ ❌ ✅ ❌ ❌
取消订单 ✅ ❌ ❌ ✅ ❌ ❌
渠道回调 ❌ ✅ ❌ ❌ ❌ ❌
发起退款 ❌ ❌ ✅ ❌ ❌ ❌
退款回调 ❌ ❌ ❌ ❌ ✅ ❌
超时关闭 ✅ ✅ ❌ ❌ ❌ ❌
边界情况：“支付失败”状态下允许“发起支付”，但此时应生成新的支付流水号，而非复用原流水号。复用流水号会导致渠道侧幂等冲突，引发重复支付风险。

4.6 状态枚举的扩展性设计

实际业务中可能引入更多状态，例如“部分退款”、“支付超时”、“风控冻结”。扩展时应遵循以下原则：

  • 向后兼容：新增状态不改变已有状态的语义和转换路径。
  • 状态码命名：使用 PARTIAL_REFUND、TIMEOUT、FROZEN 等自描述名称。
  • 数据库迁移：使用 ALTER TABLE ... ADD CONSTRAINT 更新 CHECK 约束，而非重建表。
-- 扩展 CHECK 约束示例（PostgreSQL 16+ 支持 ALTER TABLE ... VALIDATE）
ALTER TABLE payment_order
  DROP CONSTRAINT chk_payment_order_status;

ALTER TABLE payment_order
  ADD CONSTRAINT chk_payment_order_status
  CHECK (status IN ('PENDING','PROCESSING','SUCCESS','FAILED',
                    'REFUNDING','REFUNDED','PARTIAL_REFUND','TIMEOUT'));

-- 对已有数据做校验（不阻塞读写）
ALTER TABLE payment_order
  VALIDATE CONSTRAINT chk_payment_order_status;
← 上一章 📖 返回目录 下一章 →