前端防重复提交需禁用按钮并配合pending状态与AbortController，校验失败须恢复按钮和焦点，服务端必须实现幂等性兜底。
提交前用 disabled 锁住按钮但别只靠它
单纯给 submit 按钮加 disabled="disabled" 能视觉上阻止二次点击，但绕过非常容易：用户刷新页面、F5 重发、或直接调用 form.submit()。更关键的是，如果校验失败后没恢复按钮状态，用户就卡死了。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 在
submit事件处理器开头立即设button.disabled = true - 校验失败时必须同步执行
button.disabled = false - 不要依赖表单的
onsubmit="return false"做唯一控制，它不拦截 js 主动提交 - 服务端仍需幂等设计（如用
idempotency-key头或订单号去重），前端锁只是体验层防护
fetch 提交时用 AbortController 配合 pending 状态
当用 fetch 替代原生表单提交时，重复点击会导致多个请求并发发出。仅靠禁用按钮还不够——如果用户快速连点两次，第一次请求还没发完，第二次的 fetch 已经启动。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 声明一个
let pending = false变量，在发起请求前判断并提前return - 配合
AbortController，在新请求发起时调用上一个abort()，避免旧请求“幽灵执行” - 请求结束（无论成功失败）都重置
pending = false和按钮状态 - 注意：
AbortController不会中止已响应的请求，只中断未完成的网络传输
后端返回 201/200 后前端跳转前清空表单或重定向到新页面
跳转本身不是问题，问题是跳转逻辑写在 then() 里却没处理异常路径：比如接口返回 200 但业务字段提示“已存在”，此时若仍执行 window.location.href = '/success'，用户刷新就会重复提交。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 只在明确收到成功业务态（如
response.data.code === 0）后再跳转 - 跳转前调用
form.reset()或手动清空input.value，防止用户回退后再次提交残留数据 - 更稳妥的做法是服务端返回 303 See Other，由浏览器自动跳转，天然规避 F5 重发
- 避免在
catch里跳转错误页的同时还保留原表单，这会让用户误以为可以再试一次而重复触发
校验失败时恢复按钮状态和焦点，别让用户“摸黑操作”
很多实现校验失败后忘了把按钮设回 enabled，或者没聚焦到第一个报错字段，用户看不到错误提示，只会反复猛点按钮，反而加剧误操作。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 所有校验分支（包括异步校验如用户名是否可用）结束后，统一走按钮状态恢复逻辑
- 校验出错时用
element.focus()定位到首个错误input，并滚动到可视区域（element.scrollIntoView({ behavior: 'smooth' })） - 不要用
alert()中断流程，它阻塞 JS 执行且无法定制样式，容易被用户忽略 - 如果用了第三方校验库（如
validator.js），确认其validate()方法是同步返回布尔值，还是返回 promise —— 异步校验必须 await 完再决定是否放行提交
实际中最容易被忽略的是服务端幂等性兜底。前端一切锁机制都可能被绕过，只要用户能拿到原始请求参数，就能用 curl、postman 或开发者工具重放。所以 idempotency-key 或业务唯一键（如支付单号）的校验必须落在数据库写入之前。