典型电商支付流程：前端防护下重复支付的真实场景及生产案例问询

一、典型电商流程中前端防护仍失效的真实场景 #

• 网络波动引发的「假失败」：用户点击支付按钮后，前端发起请求但遭遇网络延迟，前端触发超时逻辑跳转至失败页，但后端实际已经收到请求并完成支付。用户误以为支付失败，重新进入支付页发起新请求，就会产生重复扣款——前端跳转逻辑无法阻止用户发起新的支付流程，而旧流程的支付其实已成功。
• 浏览器回退/缓存导致的状态重置：用户支付成功跳转后，点击浏览器回退按钮回到支付页，此时页面重新渲染，按钮禁用的状态丢失，用户再次点击发起请求；或是浏览器缓存了未更新的支付页，按钮未被禁用，用户误触发起重复请求。
• 前端代码兼容性异常：部分旧版浏览器（如IE11）不支持某些JS语法，导致按钮禁用逻辑执行失败；或是异步请求的钩子函数出错，按钮未及时被禁用，用户快速连续点击两次，两个支付请求都发送至后端。
• 第三方支付回调延迟：前端发起请求至第三方支付平台（如微信支付），平台已完成扣款，但回调通知后端时超时，前端跳转失败页。用户以为支付失败，重新发起支付，平台再次完成扣款，造成重复支付。

二、生产环境中遇到的前端控制失效案例 #

之前在电商公司做支付系统维护时，遇到过真实的重复支付问题：
移动端用户用4G网络支付，点击按钮后前端立即禁用按钮并发送请求，但因网络信号不稳定，请求在传输中出现丢包，前端10秒超时后跳转失败页。用户以为支付失败，返回订单页重新进入支付流程，再次发起支付。但实际上第一次请求并未完全丢失，第三方支付网关延迟12秒后收到请求并完成扣款，第二次请求也成功扣款，导致同一订单被重复扣了两次费用。
事后排查发现，前端超时设置过短，且后端未做幂等校验，前端的防护逻辑完全拦不住这种网络延迟导致的重复请求。

内容的提问来源于stack exchange，提问作者samsamsamsmasma