有效防止表单重复提交需分层协作：按钮状态控制（禁用+视觉反馈+超时兜底）+函数节流/防抖（节流适配连续操作，防抖适配最终意图）+请求级去重（哈希判重、token幂等、数据比对）+事件净化（去重绑定、flag标志、统一入口）。
防止表单重复提交和节流控制，本质是解决“用户高频操作”与“请求不可重入”之间的矛盾。单纯禁用按钮只能拦住点击，拦不住快速切换、事件重复绑定、或接口未响应时的二次触发。真正有效的方案需分层协作：按钮状态控制 + 函数节流/防抖 + 请求生命周期管理。
按钮禁用与状态反馈
这是最直观的用户层防护，关键不是“禁用”，而是“禁用得准、恢复得稳”：
- 用 prop("disabled", true) 禁用按钮（非 attr），确保 DOM 属性与实际可交互状态一致
- 在 complete 回调中恢复按钮（不是只写 success 或 error），避免网络异常、超时、服务端报错导致按钮永久锁定
- 添加视觉提示：如将按钮文字改为“提交中…”、加 loading 动画，降低用户焦虑感
- 设置超时兜底：例如 4000ms 后自动恢复按钮并提示“请求超时，请重试”，避免用户卡死
节流（Throttle）与防抖（Debounce）选型
节流和防抖不是互斥方案，而是适配不同场景的逻辑层过滤：
- 节流适用于固定节奏操作：比如按钮连续点击、滚动加载、筛选条件切换。设定 1000ms 间隔，期间只允许执行一次请求，适合“不想漏掉任何一次意图，但也不愿堆叠”的场景
- 防抖适用于最终意图明确的操作：比如搜索框输入、表单实时校验。延迟 300–500ms 执行，若用户持续输入，就只发最后一次，避免中间冗余请求
- 注意：节流时间不能硬设为“比平均响应时间长”，而应结合业务容忍度——例如支付按钮用节流反而不合适，更适合用防抖+唯一标识
请求级去重与唯一标识
前端拦截再严，也挡不住绕过 JS 的请求或页面刷新后重提。因此需在请求发起前做语义级判断：
- 对同一接口（URL + 序列化参数）生成哈希值，维护一个 pending map：若该哈希已存在未完成请求，新请求直接丢弃或取消旧请求（用 AbortController）
- 为每次提交生成临时 token（如 UUID），存入 localStorage 并随请求发出；成功/失败后立即清除。后端校验 token 是否已用过，实现幂等性
- 表单数据缓存比对：提交前将 form.serialize() 结果与上一次成功提交的字符串对比，相同则跳过——适合内容几乎不变、仅因等待焦虑而重点的场景
事件监听净化与状态标志位
很多重复请求其实源于代码层面的疏忽：
- 检查是否多次绑定同一事件（如页面重绘、模块重复初始化），用 off() 再 on() 或使用事件委托统一管控
- 引入全局 flag 变量（如
let isSubmitting = false），在请求开始前判断，true 则 return；务必在 complete 中重置，且避免闭包污染 - 对于 Enter 提交、快捷键等多入口操作，统一收口到一个处理函数，避免分散逻辑导致 flag 漏控
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
