防止表单重复提交的全面解决方案
表单重复提交是指用户在短时间内多次点击提交按钮,或者在提交后刷新页面，导致服务器接收到多次相同的请求，从而产生重复数据（如重复下单、重复注册）的问题。
前端预防方案
前端方案主要用于提升用户体验，通过限制用户操作来降低重复提交的概率，但不能作为唯一的安全保障。
- 禁用提交按钮：在用户点击提交按钮后，立即将按钮状态设置为
disabled，直到请求完成或超时。 - 加载状态提示：在提交过程中显示 Loading 动画或遮罩层，防止用户在等待响应时再次点击。
- 防抖（Debounce）与节流（Throttle）：
- 防抖：在最后一次点击后的指定时间内才发送请求。
- 节流：在规定时间内只允许发送一次请求。
- 提交确认弹窗：对于高风险操作（如支付），在提交前弹出确认对话框。
后端拦截方案
后端方案是确保数据一致性的核心，必须实现真正的幂等性（Idempotency）。
- Token 令牌机制（最常用）：
- 流程：用户进入页面时，服务器生成一个唯一的 Token 存入 Session 或 Redis，并发送给前端。
- 校验：用户提交表单时携带该 Token，服务器校验 Token 是否存在且正确。
- 销毁：校验通过后，立即删除该 Token，如果用户再次提交，由于 Token 已失效，请求将被拦截。
- 幂等性 Key（唯一请求 ID）：
- 客户端在请求头中携带一个由 UUID 生成的
Request-ID。 - 服务端在处理前检查该 ID 是否在缓存（如 Redis）中存在。
- 如果存在且状态为“处理中”或“已完成”，则直接返回结果，不再重复执行业务逻辑。
- 客户端在请求头中携带一个由 UUID 生成的
- 数据库唯一索引（兜底方案）：
- 为具有唯一性约束的字段（如：订单号、用户 ID + 业务类型）建立 Unique Index。
- 当重复数据尝试插入时,数据库会抛出唯一键冲突异常，从而强制拦截。
- 分布式锁（Redis SetNX）：
- 在处理请求前,尝试在 Redis 中设置一个以用户 ID 为 Key 的锁。
- 设置过期时间以防止死锁。
- 如果设置失败,说明当前有相同请求正在处理，直接返回“请勿重复提交”。
架构模式：PRG 模式
PRG (Post/Redirect/Get) 是处理表单提交的经典 Web 设计模式，旨在解决用户刷新页面导致重复提交的问题。
- Post：用户提交表单数据到服务器。
- Redirect：服务器处理完请求后，不直接返回 HTML 页面，而是发送一个 302 重定向 响应。
- Get：浏览器接收到重定向指令，自动发起一个 GET 请求跳转到结果页面。
- 效果：用户在结果页面刷新时，执行的是 GET 请求而非 POST 请求，因此不会触发重复提交。
方案对比与总结
| 方案 | 实现难度 | 拦截强度 | 适用场景 |
|---|---|---|---|
| 前端禁用按钮 | 低 | 低 | 基础用户体验优化 |
| Token 机制 | 中 | 高 | 绝大多数 Web 表单 |
| 幂等 Key | 中 | 极高 | API 接口、分布式系统 |
| 唯一索引 | 低 | 极高 | 数据库层面的最终保障 |
| PRG 模式 | 低 | 中 | 防止页面刷新导致的重复提交 |
| 分布式锁 | 高 | 高 | 高并发、对实时性要求极高的场景 |
最佳实践建议：采用 “前端禁用按钮 + 后端 Token/幂等 Key + 数据库唯一索引” 的组合拳，构建多层防御体系。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/493498.html
