防止表单重复提交的核心是阻止后续无效请求发起，而非取消已发出请求；需结合禁用按钮+状态锁、abortcontroller可控取消及后端幂等设计。
在表单提交时防止重复点击导致的多次请求，核心不是“取消已发出的请求”，而是**阻止后续无效请求的发起**。因为用户点击提交后，若网络慢或接口响应延迟，容易连续点击，造成重复提交（如重复下单、重复保存）。虽然 AbortController 可以取消未完成的 fetch 请求，但它无法撤回已到达服务端的请求，也无法解决前端重复触发的问题。真正可靠的做法是「防重 + 可控取消」结合。
禁用提交按钮 + 状态锁
最直接有效的方式是在首次点击后立即禁用按钮并标记提交中状态，阻止二次触发：
- 给 submit 按钮添加
disabled属性，并设为true，同时修改文字（如“提交中…”）提升用户体验 - 使用一个布尔变量（如
isSubmitting）或 React 的useState管理状态，提交前校验，为true则直接return - 无论请求成功或失败，都需在
finally中恢复按钮和状态，避免“假死”
配合 AbortController 主动取消上一次请求（可选增强）
当用户快速连续点击，且前一次请求尚未结束时，可主动中止它，避免资源浪费：
- 在组件作用域（或闭包）中维护一个
abortController实例 - 每次新提交前，先调用
abortController.abort()（如果存在且未终止），再新建一个控制器 - 将新控制器的
signal传入fetch或axios（axios 需通过cancelToken或 v0.22+ 的signal支持） - 注意：仅适用于还未响应的请求；已发送到后端的仍会执行，所以仍需后端幂等设计
后端配合：幂等性是根本保障
前端防重只是第一道防线，不能替代服务端校验：
- 为关键操作（如支付、创建订单）生成唯一请求 ID（如前端生成
idempotency-keyHeader），后端据此判断是否已处理过该操作 - 数据库写入前检查业务唯一约束（如订单号、用户+时间窗口组合）
- 即使前端没防住、网络重试、F5 刷新，也能保证结果一致
补充：防抖不适用表单提交场景
不要用防抖（debounce）来处理表单提交：
- 防抖会延迟执行，用户点击后无即时反馈，体验差
- 表单提交是明确的“一次性意图”，不是高频输入事件（如搜索框）
- 它无法解决“已点击但请求还在跑”的并发问题，只推迟了问题发生时间
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
