1. 课程导入
在多数互联网业务中，支付看似只是“调一个接口、返回成功或失败”，但真正落到生产系统，支付网关要同时面对多渠道接入、重复支付、超时补偿、退款对账、风控拦截、分账结算等复杂问题。统一收单与交易编排，正是把这些分散能力收敛到一套可治理、可观测、可扩展的架构中。本章作为课程导入，先建立全局认知：我们到底要解决什么问题，用什么方法解决，以及后续 29 章会沿着怎样的路线逐步展开。
一、学习目标：从“能支付”到“支付可控”
本课程不是单纯讲解某个支付 SDK 的调用方式，而是围绕支付网关的工程化建设展开。学完本课程，你应当具备以下能力：
- 统一收单能力：能够设计一套面向多支付渠道（微信、支付宝、银联、银行直连、海外钱包等）的统一收单接口，屏蔽渠道差异。
- 交易编排能力：能够把“下单—支付—回调—查询—退款—对账”等步骤编排为可配置、可重试、可补偿的状态机流程。
- 资金安全与一致性：理解幂等、状态机、最终一致性、TCC/SAGA 在支付场景中的落地方式。
- 可观测与可运维：掌握支付链路的日志、埋点、告警、对账与故障复盘方法。
- 架构演进判断：能够根据业务规模，判断何时从单体收银台演进到统一支付网关与交易编排平台。
学习建议：每章都带着一个真实问题去读，例如“用户重复点击支付按钮怎么办”“渠道回调丢了怎么办”“退款成功但账没平怎么办”。支付网关的价值，往往体现在这些异常路径上。
二、核心概念：统一收单、交易编排与支付网关
在进入实战之前，需要先厘清三个容易混淆的概念。
| 概念 | 关注点 | 典型职责 | 常见误区 |
|---|---|---|---|
| 统一收单 | 渠道差异屏蔽 | 统一下单、统一回调、统一查询、统一退款接口 | 以为只是“多写几个 if else 判断渠道” |
| 交易编排 | 流程与状态管理 | 状态机、重试、补偿、超时、幂等、事务边界 | 把编排等同于简单串行调用 |
| 支付网关 | 入口与治理 | 路由、鉴权、限流、签名、日志、监控、灰度 | 只做转发，不做业务语义沉淀 |
三者关系可以理解为：支付网关是入口，统一收单是能力层，交易编排是流程层。网关负责“接进来”，收单负责“对得上”，编排负责“跑得稳”。缺少任何一层，支付系统都会在规模扩大后出现难以维护的“渠道泥潭”。
三、整体框架：从请求入口到资金落账
一个典型的统一收单与交易编排平台，通常包含以下层次：
- 接入层：API 网关、签名验签、限流熔断、商户鉴权、请求日志。
- 收单层：统一下单、支付方式路由、渠道适配器、回调统一处理。
- 编排层：交易状态机、流程引擎、幂等控制、重试与补偿、超时任务。
- 资金层：退款、对账、分账、结算、账务流水。
- 支撑层：配置中心、消息队列、分布式锁、监控告警、数据大盘。
下面用一张结构关系图展示各层之间的数据流与依赖关系。图中重点表达“请求如何进入、状态如何流转、异常如何补偿”，而不是简单罗列模块名称。
四、实战路线图：30章如何一步步落地
本课程后续内容将按照“认知—设计—实现—治理—复盘”的路径推进，整体可分为五个阶段：
- 阶段一（第1—5章）：建立统一收单模型，理解支付渠道差异、接口抽象与路由策略。
- 阶段二（第6—12章）：设计交易状态机与编排引擎，解决幂等、重试、补偿、超时问题。
- 阶段三（第13—20章）：实现回调处理、退款、对账、分账等资金链路能力。
- 阶段四（第21—26章）：建设可观测体系、灰度发布、压测与故障演练。
- 阶段五（第27—30章）：综合案例复盘，完成从单体收银台到统一支付网关的架构演进。
实战路线图的核心逻辑：先统一接口，再统一状态，最后统一治理。顺序颠倒，往往会导致“接口统一了但状态对不上”或“状态机很漂亮但渠道接不进来”。
五、常见误区与复盘视角
在真实项目中，支付网关建设最容易踩的坑，往往不是技术难度，而是认知偏差。以下四个误区值得提前警惕：
- 把支付当普通接口：支付涉及资金，必须考虑幂等、对账和补偿，不能只关注 HTTP 200。
- 过度依赖渠道回调：回调可能丢失、延迟或重复，必须配合主动查询与定时补偿。
- 状态机设计过粗：只有“成功/失败”两态，无法表达“支付中”“待退款”“部分退款”等中间状态。
- 忽视对账与日志：没有完整流水和可追溯日志，出现资金差异时无法定位。
复盘视角：每一次支付故障，都应该回答三个问题——钱有没有丢？状态有没有错？用户有没有被重复扣款？这三个问题，也是后续所有章节设计取舍的最终判断标准。
本章作为导入，不要求你立刻写出代码，但需要你建立一张“全局地图”：知道统一收单解决渠道差异，交易编排解决流程一致性，支付网关解决入口治理。接下来的章节，我们会沿着这张地图，逐层拆解、逐段实现，最终形成一套可落地的支付网关统一收单与交易编排方案。