重复支付通常来自用户连续点击、页面刷新、网络超时后再次提交，或同一订单被多个终端同时打开。只依赖前端按钮防抖无法彻底解决问题，业务系统需要从订单号、状态机、数据库约束和退款流程多个层面建立防重机制。
一、为每次购买生成唯一订单号
订单号应由服务端生成，并在数据库中设置唯一索引。用户重新打开支付页面时，应优先复用仍在有效期内的待支付订单，而不是每次都新建订单。订单号必须与用户、商品、金额和创建时间关联，方便后续核对。
二、提交支付前先锁定订单
创建支付请求时，可通过数据库行锁、乐观锁版本号或分布式锁限制并发。锁的作用是保证同一订单在同一时间只生成一个有效支付请求。锁需要设置合理过期时间，避免应用异常后订单永久无法继续支付。
三、前端防抖只能作为体验优化
用户点击支付按钮后应立即显示处理中状态并暂时禁用按钮，但服务端仍要校验订单状态。即使用户刷新页面或绕过前端限制，服务端也只能接受一次从待支付到支付中的合法状态变更。
四、支付回调继续执行幂等校验
收到回调后，系统应核对订单号、交易号、金额和签名。只有订单首次从待支付变为已支付时才执行发货或充值。若同一交易号重复通知，直接返回成功；若同一订单出现不同交易号，则应进入异常队列人工核查。
五、识别真正的重复到账
重复通知不等于重复到账。只有收款记录中出现两笔独立交易，并且都能匹配同一业务购买，才属于重复付款。处理前应保留原始通知、到账记录和用户操作日志，避免把正常的重试误判为重复支付。
六、建立清晰的退款规则
确认重复到账后，可保留最早成功的一笔，将后续重复款项原路退回。退款记录应关联原交易号、退款金额、操作人和处理原因。退款完成后通知用户，并在订单后台保留完整审计轨迹。
七、持续观察异常指标
建议统计同一订单多次创建支付请求的次数、不同交易号命中同一订单的数量、重复退款率和前端重复点击率。若异常集中发生在某个页面或渠道，应优先检查超时设置、按钮交互和接口重试策略。
八、设计订单状态机
建议将订单分为待支付、支付中、已支付、已关闭、退款中和已退款等状态，并明确每个状态允许的下一步操作。状态改变必须写入审计日志，避免客服、异步通知和定时任务同时修改同一订单。
九、用户侧提示与客服处理
用户支付后页面应展示订单号、处理中状态和刷新入口。遇到网络超时不能引导用户反复付款，而应优先查询已有订单。客服处理时应核对订单号、交易号、金额和时间，不通过口头截图直接确认到账。
十、上线前检查清单
确认订单号有唯一索引；创建支付请求有并发保护；回调验签、金额校验和幂等更新已完成；异常订单进入人工队列；退款可追溯；告警覆盖重复交易和交付失败。完成这些检查，才能把重复支付从偶发故障变成可控流程。
防止重复支付的关键是让订单状态变更具有唯一性，让业务交付具有幂等性。前端防抖改善体验，服务端唯一约束和状态机保证数据正确，完善的退款流程则负责处理少量真实重复到账。
