XuLaLa.Tech

在开发 web 应用时，表单重复提交是一个常见且容易忽视的问题。用户可能会因网络延迟、页面卡顿等原因多次点击提交按钮，从而导致同一表单被重复提交。重复提交不仅会给用户带来困惑，还可能引发数据一致性、重复支付等严重后果。因此，防止表单重复提交是一个重要的开发实践。那么，应该在前端还是后端来做限制呢？

文章目录

• 1 一、前端限制
  • 1.1 禁用提交按钮
  • 1.2 使用防抖（Debounce）或节流（Throttle）
• 2 二、后端限制
  • 2.1 使用 Token 校验（CSRF 防御）
  • 2.2 幂等性设计
• 3 三、前后端结合的方案
  • 3.1 综合方案：

一、前端限制

前端限制通常是在用户提交表单后，立即采取一些措施，防止用户再次提交。常见的方法有以下几种：

禁用提交按钮

当用户点击提交按钮时，可以通过 JavaScript 立即禁用该按钮，防止用户再次点击。例如：

document.querySelector('form').addEventListener('submit', function() {
document.querySelector('button[type="submit"]').disabled = true;
});

优点：

• 实现简单：通过几行 JavaScript 代码即可完成。
• 用户体验好：用户点击后，按钮状态发生变化，避免再次误操作。

缺点：

• 不安全：禁用按钮的逻辑在客户端，用户可以通过浏览器开发者工具手动绕过禁用。
• 网络问题：在网络延迟或页面卡顿时，用户可能会尝试刷新页面或重新提交表单。

使用防抖（Debounce）或节流（Throttle）

防抖和节流技术可以限制表单在一定时间内只能提交一次。例如，防抖可以确保在短时间内多次点击提交按钮只触发一次提交。

优点：

• 控制频率：能有效防止用户快速连续点击提交按钮。
• 可配置：开发者可以根据场景设置合适的时间间隔。

缺点：

• 无法彻底防止重复提交：如果用户刷新页面，防抖和节流的效果会失效。
• 前端依赖：仍然是客户端的逻辑，容易被绕过。

二、后端限制

后端限制通常通过在服务器端对每次请求进行校验，从根本上防止表单重复提交。

使用 Token 校验（CSRF 防御）

每次表单提交时，服务器会生成一个唯一的 token，该 token 随表单一同提交，并在服务器端进行验证。一旦表单提交成功，token 就失效，防止再次提交。

优点：

• 安全性高：即使用户刷新页面或绕过前端限制，后端校验 token 可以有效防止重复提交。
• 无需依赖客户端：所有逻辑都在服务器端进行，用户无法绕过。

缺点：

• 实现复杂：需要维护 token 的生成和验证机制。
• 性能影响：在高并发场景下，生成和验证 token 可能会增加服务器的负担。

幂等性设计

某些业务场景下，后端可以通过幂等性来处理重复请求。幂等性意味着同一个操作多次执行的结果与一次执行的结果相同。例如，支付操作可以通过唯一订单号来确保同一订单只支付一次。

优点：

• 根本解决问题：通过业务逻辑设计，从根本上避免重复提交带来的副作用。
• 灵活性高：适用于需要精确控制数据处理流程的场景。

缺点：

• 业务依赖：幂等性设计需要根据业务场景进行定制，不是通用方案。
• 实现复杂：在某些业务场景下，保证幂等性需要额外的开发工作。

三、前后端结合的方案

在实践中，最好采用前后端结合的方式来防止表单重复提交。前端可以通过禁用按钮、防抖等手段提升用户体验，而后端则通过 token 校验、幂等性设计来保证安全性。

综合方案：

1. 前端：
   • 禁用提交按钮：防止用户重复点击。
   • 防抖或节流：避免高频点击造成多次提交。
2. 后端：
   • 使用 token 校验：确保每次表单提交都唯一且安全。
   • 业务逻辑中设计幂等性：确保重复请求不会导致数据异常。

防止表单重复提交既可以在前端处理，也可以在后端处理，但最安全可靠的做法是结合前后端的限制措施。前端的操作能够提升用户体验，避免因网络延迟或误操作导致的重复提交；后端的校验则确保了数据的完整性和安全性。结合这两者，可以有效防止表单重复提交的问题，从而提升应用的稳定性和安全性。