别再只靠"禁用按钮"了！真正的防重提交，需要前后端协同。
在电商下单、用户注册、支付发起等关键场景中，用户连点多次"提交"按钮 是再常见不过的行为。
轻则造成数据库写入多条重复记录，重则导致用户被扣款两次、库存超卖------这绝不是危言耸听。
那么，前端该如何有效防止重复提交？
本文将从用户体验 和系统可靠性 两个维度，为你梳理 4 种主流方案，并告诉你：为什么"禁用按钮"远远不够？
方案一：提交时禁用按钮（基础但必要）
最直观的做法：点击后立即禁用提交按钮。
js
const submitBtn = document.getElementById('submit-btn');
const form = document.getElementById('my-form');
form.addEventListener('submit', (e) => {
e.preventDefault();
if (submitBtn.disabled) return; // 防止多次触发
submitBtn.disabled = true;
submitBtn.textContent = '提交中...';
fetch('/api/submit', { method: 'POST', body: new FormData(form) })
.then(res => res.json())
.then(data => {
alert('提交成功！');
})
.catch(err => {
alert('提交失败，请重试');
})
.finally(() => {
submitBtn.disabled = false;
submitBtn.textContent = '提交';
});
});优点 ：简单、直观、提升 UX。
致命缺陷：
- 用户刷新页面后状态丢失；
- 无法阻止通过脚本、Postman 等绕过 UI 的重复请求；
- 仅靠前端，防不住！
结论：这是必备的第一道防线，但绝不能是唯一防线。
方案二：使用防重 Token（推荐！前后端协同）
这才是企业级应用的标准做法。
原理：
- 页面加载时，后端生成一个一次性 token（如 UUID），并存入 Session 或 Redis；
- 前端在表单中携带该 token 提交；
- 后端收到请求后：
- 检查 token 是否存在且未使用；
- 若有效，则标记为"已使用"并处理业务；
- 若无效或已用过，直接拒绝。
html
<!-- 表单中隐藏 token -->
<input type="hidden" name="antiReplayToken" value="a1b2c3d4-5678-90ef..." />
js
// 提交时无需额外处理，token 随表单自动发送优势：
- 即使用户刷新、多开标签页，每个 token 只能用一次；
- 能防御脚本刷接口、自动化工具攻击；
- 与业务解耦，通用性强。
注意：
- Token 必须有时效性（如 5 分钟过期）；
- 必须由后端生成和校验，前端不可伪造。
方案三：前端加锁 + 请求去重（适用于 API 场景）
如果你调用的是无表单的 API（如点击"领取优惠券"按钮），可用"请求指纹"去重。
js
const pendingRequests = new Set();
function requestWithDedup(key, apiCall) {
if (pendingRequests.has(key)) {
console.log('请求正在进行，忽略重复');
return Promise.reject('Duplicate request');
}
pendingRequests.add(key);
return apiCall().finally(() => {
pendingRequests.delete(key);
});
}
// 使用示例
document.getElementById('claim-btn').addEventListener('click', () => {
const userId = 'user_123';
requestWithDedup(`claim_${userId}`, () =>
fetch('/api/claim-coupon', { method: 'POST' })
);
});适用场景：
- 按钮触发的独立操作（非完整表单）；
- 需要防止同一用户短时间内多次触发同一操作。
方案四：结合 loading 状态 + 全局拦截（提升体验）
在大型应用中，可借助状态管理（如 Redux、Pinia）或 Axios 拦截器统一处理。
js
// Axios 示例
let isSubmitting = false;
axios.interceptors.request.use(config => {
if (config.url === '/api/submit-order') {
if (isSubmitting) throw new Error('请勿重复提交');
isSubmitting = true;
}
return config;
});
axios.interceptors.response.use(
res => {
if (res.config.url === '/api/submit-order') isSubmitting = false;
return res;
},
err => {
if (err.config?.url === '/api/submit-order') isSubmitting = false;
return Promise.reject(err);
}
);这种方式适合 SPA 应用，能覆盖所有相关请求。
最终建议：分层防御，才是王道
| 层级 | 措施 | 作用 |
|---|---|---|
| 前端 UX 层 | 禁用按钮 + loading 提示 | 阻止普通用户误操作 |
| 前端逻辑层 | 请求去重 / 状态锁 | 防止快速连点 |
| 后端安全层 | 防重 Token / 幂等设计 | 根本性防御重复提交 |
| 数据库层 | 唯一索引（如订单号） | 最后一道保险 |
记住：前端可以被绕过，后端必须守住底线。
结语
防止重复提交，不是"加个 disabled 就完事"，而是一套纵深防御体系 。
从用户体验到系统安全，每一步都不可或缺。
下次当你看到"提交中..."的按钮时，不妨想想：你的系统，真的扛得住用户狂点十次吗？
你们项目是怎么做防重提交的？欢迎在评论区交流最佳实践！
各位互联网搭子，要是这篇文章成功引起了你的注意，别犹豫，关注、点赞、评论、分享走一波，让我们把这份默契延续下去，一起在知识的海洋里乘风破浪！