一、真实场景：不是接口慢，是被“点崩”的

很多系统事故，并不是性能问题。

而是用户做了这些事：

• 提交按钮没反应 → 连点 3 次
• 切换页面太快 → 上一个请求还在跑
• 搜索框疯狂输入 → 接口一秒打十几次

最后结果只有一个：

重复请求、脏数据、库存扣多、工单爆炸

而大多数项目，一开始都忽略了这件事。

二、为什么「防重复提交」单独做是不够的？

很多人第一反应是：

“我加个 loading，不让点不就完了？”

但现实是：

• 页面切换，请求还在后台跑
• 参数变化，新请求已发出，旧请求还在返回
• 网络延迟，旧请求后返回却覆盖新数据

光防点击，根本兜不住。

三、真正稳的方案：两件事必须一起做

✅ 请求取消
✅ 防重复提交

不是选一个，是必须组合拳。

四、什么是「请求取消」？为什么它这么关键

简单理解一句话：

用户已经不关心的请求，就不该再回来捣乱

典型场景：

• 搜索框输入 a → ab → abc
• 实际上前两个请求已经没意义了
• 但它们还是会返回，而且可能最后返回

这时候如果不取消：

页面数据一定乱

请求取消的核心价值只有一个：

只认「最新一次操作」

五、防重复提交，真正防的是「逻辑重复」

防重复提交不是防用户，是防系统出事：

• 同一个订单创建多次
• 同一个表单重复保存
• 同一个流程被触发多遍

正确的目标是：

同一时间，只允许一个“有效提交”存在

而不是让用户“少点几下”。

六、我是怎么在项目里落地的（不贴代码版）

我在项目里统一做了三层兜底：

① 请求层：自动取消旧请求

• 相同接口 + 新参数 → 旧请求直接作废
• 页面离开 → 所有未完成请求清空

页面再快也不怕乱数据

② 交互层：提交自动上锁

• 提交中 → 禁止再次提交
• 请求结束 → 自动解锁

再怎么点，也只会成功一次

③ 业务层：后端兜最后一道

• 同一业务请求 → 唯一标识校验
• 已处理 → 直接返回成功结果

防前端失误，也防恶意请求

七、上线后的真实变化

这套方案上线后，最明显的变化是：

• ❌ 工单里「重复提交」几乎消失
• ❌ 数据修复次数明显下降
• ✅ 前端异常反馈减少
• ✅ 后端接口压力更可控

一句话总结：

这是那种“平时没人夸，出事能救命”的方案

八、写给还没踩坑的人一句忠告

如果你现在的系统：

• 没做请求取消
• 防重复只靠按钮 disable
• 后端完全信任前端

那不是“没问题”，只是：

问题还没轮到你

你现在的项目里：

• 有没有遇到过重复提交的坑？
• 是前端处理，还是后端兜底？
• 出过线上事故吗？

欢迎评论区聊聊。