一次线上促销活动中，用户点击提交订单后页面长时间没有响应，随后系统自动重试了一次请求。结果用户收到两条下单成功通知，库存被扣了两次，财务对账时才发现同一用户在同一时间出现了两笔金额相同的订单。这类问题往往不是某一行代码写错了，而是超时重试与幂等设计没有对齐，重试把原本偶发的网络抖动放大成了业务事故。
先判断超时发生在哪一层
排查重复下单，第一步不是改代码，而是定位超时发生的位置。客户端超时、网关超时、服务端处理超时，三者的重试行为完全不同。客户端超时后用户可能手动再点一次；网关超时后可能由网关层自动重发；服务端处理超时则可能业务已执行但响应没有返回。如果三层都配置了重试，一次用户操作可能变成三次甚至更多次请求。核对时要先画出请求链路，确认哪些环节配置了自动重试，哪些环节只是超时中断而没有重发，避免把叠加重试误判为单次异常。
核对唯一标识与幂等键的生成位置
判断重复请求能否被识别，关键看唯一标识在哪里生成。比较稳妥的做法是客户端在发起下单前生成一个请求号，随请求一起提交，服务端以该请求号作为幂等键做去重。如果幂等键是在服务端收到请求后才生成，那么两次重试会各自生成不同的键，去重逻辑形同虚设。还要核对业务单据号与幂等键是否分离：订单号可以在业务确认后生成，但幂等键必须在第一次请求时就固定下来。检查时可以直接查看日志中同一用户短时间内的多次请求，看它们携带的标识是否一致。
检查重试次数、退避策略与超时阈值
重试不是越多越好。需要核对三个参数是否匹配：单次请求的超时阈值、最大重试次数、重试间隔的退避策略。如果超时阈值设得过短，而服务端实际处理时间接近该阈值，就会频繁触发重试；如果重试间隔固定且很短，重试请求会集中打在服务端尚未完成处理的时段。合理的做法是超时阈值略大于服务端正常处理耗时的上限，重试次数控制在有限范围，并采用逐步拉长的退避间隔。同时要确认重试只针对可安全重放的请求，下单这类写操作必须依赖幂等键保护，不能仅靠减少重试次数来规避。
梳理关键步骤的先后顺序与补偿方式
下单往往不是单一动作，而是下单、扣库存、扣款、发券等多个步骤的组合。要核对每个步骤的执行顺序和失败后的补偿逻辑。如果扣款在幂等校验之前执行，重复请求就会重复扣款；如果发券没有与订单号绑定，重试可能重复发放。比较清晰的做法是先完成幂等校验并锁定请求号，再按顺序执行各步骤，每一步都记录状态，失败时依据状态做补偿而不是整单重来。补偿动作本身也要幂等，避免补偿过程中再次产生重复数据。
一份可执行的幂等核对清单
上线前可以按以下顺序逐项确认：请求链路中是否存在多层自动重试；客户端是否在首次提交时生成唯一请求号；服务端是否以该请求号做去重且去重记录有合理有效期；订单号、支付流水号、券码是否各自独立生成并可与请求号关联；超时阈值与重试次数是否经过压测验证；扣款和发券是否在幂等校验之后执行；失败补偿是否有状态记录且可重复执行而不产生副作用。验证方法上，可以在测试环境模拟服务端延迟响应，观察同一请求号多次到达时是否只产生一笔有效订单，并检查库存、账务、券记录是否一致。
接口维护中的责任边界与交付记录
重复下单这类问题往往横跨客户端、网关和服务端，排查时容易出现各方都认为不是自己的环节。it数运在接口维护中通常会把请求链路、重试配置、幂等键生成位置和补偿逻辑整理成书面记录，明确每个环节由谁负责、改动时如何同步。交付时保留核对清单和验证结果，后续调整超时参数或重试策略时有据可查。技术问题说清楚，交付过程做清楚，重复订单这类隐患才能在改动前被提前发现。
