📚 课程目录第1章支付系统概述

一、支付系统概述：支付核心链路、交易状态机、对账与清算基础概念

1.1 支付核心链路：一笔交易的生命周期

支付核心链路是指从用户发起支付请求到资金最终结算到商户账户的完整路径。在Go实现的支付系统中，这条链路通常被拆解为多个微服务节点，每个节点承担明确的领域职责。理解核心链路是后续分析并发瓶颈与领域边界的前提。

链路阶段	核心动作	典型超时	并发关注点
1. 用户请求	客户端提交支付订单（金额、渠道、用户ID）	5s	网关连接池、限流
2. 风控校验	检查用户行为、设备指纹、交易频次	200ms	规则引擎并发评估
3. 订单锁定	预占库存/余额，生成支付单号	1s	分布式锁、幂等
4. 渠道调用	调用银行/第三方支付网关（、支付宝）	10~30s	HTTP连接池、异步回调
5. 结果确认	接收渠道异步通知，更新订单状态	—	消息队列积压、去重
6. 账务入账	更新用户/商户余额，记录流水	500ms	数据库行锁、事务

Go 实践提示： 核心链路中“渠道调用”阶段最容易成为并发瓶颈。Go 的 goroutine 可以轻松发起数百个并发 HTTP 请求，但必须配合 semaphore.Weighted 或自定义连接池控制并发度，避免打垮下游渠道。

1.2 交易状态机：状态流转与幂等保障

支付交易的状态机是领域模型的核心。每个支付单在生命周期内只能按照预定义的方向流转，不允许跳跃或回退。Go 中常用 iota 枚举 + 状态表驱动的方式实现状态机，避免 if-else 泛滥。

状态码	状态名称	允许的下游状态	说明
`INIT`	初始	PROCESSING, CLOSED	订单刚创建，未提交渠道
`PROCESSING`	处理中	SUCCESS, FAILED, TIMEOUT	已提交渠道，等待异步结果
`SUCCESS`	成功	REFUNDING	支付成功，资金已锁定
`FAILED`	失败	—（终态）	渠道明确返回失败
`TIMEOUT`	超时	PROCESSING（重试）	超过等待窗口，可发起查单
`REFUNDING`	退款中	REFUNDED, FAILED	退款流程独立于支付流程

Go 代码片段：状态机核心逻辑

// PaymentStatus 支付状态枚举
type PaymentStatus int

const (
    StatusInit       PaymentStatus = iota // 0
    StatusProcessing                      // 1
    StatusSuccess                         // 2
    StatusFailed                          // 3
    StatusTimeout                         // 4
    StatusRefunding                       // 5
    StatusRefunded                        // 6
)

// stateTransitions 状态转移表
var stateTransitions = map[PaymentStatus][]PaymentStatus{
    StatusInit:       {StatusProcessing, StatusFailed},
    StatusProcessing: {StatusSuccess, StatusFailed, StatusTimeout},
    StatusSuccess:    {StatusRefunding},
    StatusTimeout:    {StatusProcessing}, // 允许重试
    StatusRefunding:  {StatusRefunded, StatusFailed},
}

// CanTransition 判断状态转移是否合法
func CanTransition(from, to PaymentStatus) bool {
    for _, allowed := range stateTransitions[from] {
        if allowed == to {
            return true
        }
    }
    return false
}

并发陷阱： 状态机更新必须使用乐观锁（UPDATE ... WHERE status = ?）或分布式锁，否则并发回调会导致状态覆盖。Go 中推荐使用 sync.Mutex 保护内存状态机，或使用数据库行级锁 + 重试机制。

1.3 对账与清算基础概念

对账（Reconciliation）是支付系统保证资金一致性的最后防线。清算（Settlement）则是资金从支付渠道转移到商户账户的正式动作。两者在领域边界上分属不同子域：对账属于核算域，清算属于资金域。

1.3.1 对账流程

文件获取： 从渠道（银行、支付宝、）下载对账单文件，通常为 CSV 或固定格式文本。
解析与标准化： 将渠道账单转换为内部统一结构（交易ID、金额、时间、状态）。
逐笔比对： 以我方支付单为主键，与渠道账单进行全量或增量比对。
差异处理： 长款（我方有、渠道无）、短款（我方无、渠道有）、金额不一致、状态不一致。
调账与冲正： 对差异项生成调账流水，必要时发起冲正或补单。

1.3.2 清算流程

结算单生成： 按商户维度汇总当日成功交易，扣除手续费后生成结算单。
资金划拨： 通过银行或第三方支付渠道将资金从平台账户划拨至商户账户。
凭证归档： 保存结算凭证、银行回单，用于审计和税务。

维度	对账	清算
触发时机	T+1 凌晨批量	T+1 或 T+N（按合同）
数据源	渠道对账单 vs 内部支付流水	内部结算单 vs 银行回单
核心操作	比对、差异标记、调账	资金划拨、手续费计算
Go 并发关注点	大文件分片解析、goroutine 池比对	批量转账接口限流、幂等
失败后果	资金差异未发现，导致资损	商户未收到款项，引发投诉

1.4 本章小结

核心链路 是支付系统的骨架，Go 的 goroutine 和 channel 天然适合处理链路上的异步与并发，但必须配合连接池、限流和超时控制。
交易状态机 是领域模型的“宪法”，状态转移表驱动的方式比 if-else 更安全、可测试。并发环境下必须使用乐观锁或分布式锁保护状态更新。
对账与清算 分属核算域和资金域，领域边界清晰。对账关注数据一致性，清算关注资金流动性。Go 的并发原语（goroutine pool、sync.WaitGroup）可大幅提升对账效率。