线上很多莫名其妙的重复数据、重复扣款、重复订单、多条相同日志排查下来既不是前端bug也不是用户恶意操作根源基本都是接口不幂等。很多开发对幂等的理解很浅只要我业务逻辑没问题重复调用也没事。实际上生产环境的重复请求远比想象中多。而且这类问题极具迷惑性测试环境很难复现只会在高并发、弱网、重试机制下集中爆发。一、为什么会出现重复请求很多人以为重复请求是用户疯狂点击其实线上绝大部分重复请求来自系统机制。网关超时自动重试、前端请求重试、负载均衡转发重试、微服务调用失败重试、网络抖动丢包重试。这些重试都是静默触发的用户完全无感知但后端实实在在执行了多次业务逻辑。查询接口无所谓重复查一百次结果都一样。但写接口、变更接口、资金接口、状态更新接口一旦不做幂等就是定时炸弹。二、最常见的错误写法很多项目的“伪幂等”写法看似安全实则完全不生效。第一种先查后写判断。接口执行业务前先查数据库有没有数据有就返回没有就新增。单线程下没问题高并发瞬间击穿。两个请求同时查询都查到空双双进入新增逻辑直接产生两条重复数据。这是典型的并发竞态问题也是线上重复数据的头号元凶。第二种依靠前端防抖、禁用按钮。前端拦截只能防普通用户操作防不住接口重试、抓包重放、第三方回调重复请求。所有依赖前端的防护在后端层面等于裸奔。三、幂等失效带来的真实业务事故我之前线上遇到过一次严重问题用户支付回调重复请求接口没有幂等校验。结果同一笔订单连续多次更新状态多次发放积分、多次入账。对账的时候差值巨大排查极其痛苦。还有场景是工单创建、审批提交、库存扣减重复调用导致状态错乱、数据叠加、流程乱套。最头疼的是业务代码没有报错日志看着正常就是数据脏了。四、真正靠谱的幂等方案其实就三类不需要花里胡哨的框架常规业务稳定落地全靠这几种。唯一幂等键约束利用数据库唯一索引订单号、业务单号、流水号唯一。重复插入直接报错从物理层面杜绝重复数据最稳、最简单。分布式锁拦截重复请求同一个业务标识同一时间只允许一个请求执行执行中其他请求直接拦截返回处理中。适合更新类、复杂事务类接口。状态机前置判断已完成、已处理、成功状态的订单直接拦截不再二次处理。避免状态回写、重复变更。五、落地感悟写接口越久越明白查询接口追求速度写接口追求安全。所有更新、新增、扣款、回调、审批类接口默认必须自带幂等性。不要赌“不会重复请求”线上环境永远会出现你想不到的重试、抖动、并发。大部分数据不一致、对账不平、业务错乱的问题追根溯源都是接口缺少幂等防护导致的低级事故。