是个少女接口幂等性这事儿，做后端的朋友迟早要正面撞上。我自己的经历是，第一回碰上是在一个支付回调联调现场，对方网关重试了三次，我这边订单状态被翻来覆去地改，最后账对不上，排错排到凌晨。从那以后我就学乖了，任何写接口上线前，先问自己一句：同一笔请求被重复发过来，系统还能不能保证结果一致？这个问题想不清楚，生产环境迟早给你上一课。
这篇文章我就好好拆一拆接口幂等性，从原理讲到方案，再讲到我实际落地时踩过的坑和最终选型。内容面向正在做服务端开发的工程师，也适合刚接触分布式系统、想搞明白“为什么支付接口必须幂等”的新手。我会把那套“唯一索引 + 状态机 + 分布式锁”的组合拳完整讲透，包括每一步的设计理由和代码写法，保证你看完能直接照着做。
1. 什么是接口幂等性，为什么所有后端都绕不开它
1.1 先理解幂等性的数学原意和业务映射
幂等（Idempotent）这个词原本来自数学和抽象代数，说的是某个操作执行一次和执行多次得到的结果是相同的。比如在整数运算里，f(x) = x 就是一个典型的幂等函数，你调用多少次，输入是什么，输出就是什么，不会因为重复调用而产生额外影响。
把这个概念映射到接口层面，含义就变成了：客户端发起同一笔业务请求，无论因为网络超时重试、消息队列重复消费、还是用户手滑双击按钮，服务端处理多次的结果，必须和处理一次保持一致。注意这里说的“结果一致”，不光是返回值一样，更重要的是业务数据的最终状态一致。比如创建订单这笔操作，重复调用十次，数据库里也只能有一条订单；扣减库存的操作，重复执行，库存也只能被扣一次。
很多刚接触这个概念的同学容易把幂等和“返回相同结果”画等号，其实不对。举个例子，查询接口 GET /order/123，每次返回的可能是“待支付”“已支付”“已发货”等不同状态，因为数据本身在变化，但这不叫不幂等。真正的不幂等是，一笔扣款请求被重复执行，账户被扣了两次，或者一个订单被重复创建了两条记录，那才是灾难。
这么说吧，幂等性保护的不是“返回一模一样的响应”，而是“每一次重复请求都不会改变系统的关键业务状态”。这个理解到位了，后面看所有方案都会很通透。
1.2 哪些接口天然幂等，哪些天生有风险
HTTP 协议本身其实是定义了幂等语义的，虽然很多人日常写接口时并不在意，但理解这个基础能帮你快速判断一个接口是否需要做额外防护。
从 HTTP 方法的角度看，GET、PUT、DELETE 在语义上是幂等的。GET 是查询，不改变数据，天然幂等；PUT 是全覆盖更新，你拿同一个报文去更新同一条记录，无论执行多少次，最终数据都是一样的，因为 PUT 是把整个资源替换成请求里指定的样子；DELETE 也一样，删除一个不存在的资源，服务端返回一个“资源不存在”的提示，并不会产生副作用。
真正天生非幂等的是 POST，语义是“新建资源”。同一个 POST 请求被重复发送，理论上就会创建多条资源。而现实业务里，几乎所有高风险操作——创建订单、发起支付、提交审批、发放优惠券——都是 POST 接口。这就是为什么幂等性设计几乎总是和 POST 接口绑定在一起。
但我要提醒一点，语义上的幂等只是协议层面给的标准答案，业务领域里情况更复杂。比如 UPDATE 类操作，如果 SQL 写的是 UPDATE account SET balance = balance + 100 WHERE id = 1，这个操作就不是幂等的，因为每次执行都会让余额增加 100。而如果写成 UPDATE account SET balance = 100 WHERE id = 1，那它就是幂等的。所以，判断一个接口是否幂等，要看具体业务动作的语义，而不是只看请求方法。
1.3 最容易踩进幂等坑的三个真实场景
场景一：支付回调。第三方支付平台通知你的服务器“这笔单支付成功了”，这类回调通常有重试机制，可能同一订单在几十秒内被通知五六次。如果服务端不做幂等处理，每收到一次回调就给用户账户加一次余额，那系统离资金事故就不远了。
场景二：前端重复提交。用户在电商 App 上下单，点了“提交订单”按钮后网络卡顿，页面没有及时跳转，用户又点了一下。此时如果第一个请求其实已经到达服务端并且创建了订单，只是响应没回来，第二个请求又带着同样的商品信息进来，很容易生成两笔完全相同的订单。
场景三：消息队列重复消费。很多人用 MQ 做订单异步处理或库存扣减，但消息队列的“At Least Once”投递语义决定了，在极端情况下同一条消息可能被投递多次。你写消费者逻辑时如果没有幂等处理，重复消费一次就是多扣一次库存，这在电商大促场景里就是资损事故了。
这三个场景是我实际中遇到最多的，也是面试里考察幂等性最常问的场景。它们的共同特征是：业务动作本身不是幂等的，而触发方式天然具备重复性。这类接口，必须在设计和编码阶段就把幂等保护做进去。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 五大主流幂等方案横评与选型思路
2.1 方案一：数据库唯一索引/防重表
数据库唯一索引是落地最朴素、也最可靠的一种方案。思路是给业务数据表加一个唯一索引字段，比如订单号、支付流水号、业务唯一键，然后在写入时依赖数据库的唯一约束来挡住重复插入。
举个例子，订单表里加一个 biz_id 字段，并建立唯一索引。创建订单的接口在处理请求时，直接拿着客户端传来的 biz_id 往表里插入。如果这个 biz_id 之前已经存在，插入就会报 DuplicateEntry 异常，程序捕获到这个异常就知道这是一次重复请求，直接返回“订单已存在”的提示即可，不会产生新数据。
防重表的做法是在业务主表之外，单独建一张表