2. 幂等性基础：数学定义、HTTP 方法与业务接口

幂等性（Idempotency）是支付系统中间件设计的核心基石。理解幂等性的精确含义，区分不同 HTTP 方法的幂等语义，以及厘清业务幂等与接口幂等的差异，是后续设计幂等方案的前提。

2.1 幂等性的数学定义

在数学和计算机科学中，幂等性描述的是操作的可重复执行性。其形式化定义如下：

幂等性并不要求操作没有副作用，而是要求多次重复的副作用与单次一致。例如，将账户余额设置为 100 元是幂等的；而将账户余额增加 100 元则不是幂等的。

2.2 HTTP 方法的幂等性

HTTP 协议规范（RFC 7231）明确规定了不同方法的幂等语义。这是设计 RESTful API 和支付接口的基础。

HTTP 方法	幂等性	安全（无副作用）	典型语义	支付场景示例
GET	✅ 是	✅ 是	查询资源，不改变服务端状态	查询订单状态、查询账户余额
PUT	✅ 是	❌ 否	全量替换资源，指定目标状态	更新订单为“已支付”状态
DELETE	✅ 是	❌ 否	删除资源，删除后再次删除无变化	删除作废的支付请求记录
POST	❌ 否	❌ 否	创建资源或触发非幂等操作	创建支付订单、发起转账
PATCH	⚠️ 非标准	❌ 否	部分更新资源，需业务保证	部分退款、修改订单备注

下面通过一个 SVG 图展示 HTTP 方法在幂等性维度上的分类与关系：

2.3 业务幂等与接口幂等的区别

在实际支付系统设计中，必须严格区分两个层次的幂等性：接口幂等和业务幂等。混淆二者是导致幂等方案设计失败的常见原因。

对比维度	接口幂等（API Idempotency）	业务幂等（Business Idempotency）
关注点	同一请求被重复调用时，系统不产生重复的技术副作用	同一业务操作被重复执行时，业务结果与执行一次一致
实现层次	网关层、中间件层、API 框架层	业务逻辑层、领域模型层、数据库层
典型手段	请求去重表、Token 机制、唯一请求 ID	状态机校验、乐观锁、业务流水号唯一约束
失败后果	重复插入记录、重复发送消息、资源重复创建	重复扣款、重复退款、订单状态错乱
支付场景	防止同一支付请求被网关重复转发	防止同一笔订单被多次扣款成功

下面的 SVG 图展示了接口幂等与业务幂等在支付系统中的层次关系与协作方式：

2.4 幂等性在支付系统中的关键作用

支付系统对幂等性的要求远高于普通业务系统，原因在于：

• 资金安全：重复扣款或重复退款直接导致资金损失，属于 P0 级事故。
• 网络不确定性：支付链路长，超时重试、消息重复投递是常态。
• 监管合规：金融监管要求交易流水必须唯一、可追溯。
• 用户体验：用户不应因网络抖动而看到重复支付页面或收到重复扣款通知。