表单提交防连点需禁用按钮并恢复、用requestSubmit()替代submit()、服务端必须做幂等校验、移动端需合理处理回车提交。
表单提交按钮被连点怎么办
用户手快或网络延迟时，submit 按钮可能被多次点击，导致重复请求——后端没做幂等，订单就可能下两遍。这不是前端“美化”问题，是必须堵住的逻辑缺口。
最直接有效的做法是：点击后立刻禁用按钮，并在提交完成（无论成功失败）后再恢复。别依赖 preventDefault() 或节流函数，它们治标不治本。
- 用
button[type="submit"]，而不是input[type="submit"]，前者更容易控制disabled状态和文案 - 禁用时机必须在
form.addEventListener('submit', ...)回调里，且放在event.preventDefault()之后、实际发送请求之前 - 如果用
fetch或axios提交，务必在.finally(() => { btn.disabled = false; })中恢复按钮，否则失败后按钮永远卡死
用 form.requestSubmit() 替代 submit() 调用
手动调用 form.submit() 会绕过表单验证、不触发 submit 事件，也跳过所有原生防误触逻辑。这是很多“点了没反应”或“验证失效”的根源。
requestSubmit() 是现代标准解法：它模拟真实用户点击行为，会触发验证、冒泡、事件监听器，且兼容 disabled 按钮状态检查。
立即学习“前端免费学习笔记（深入）”；
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 不要写
form.submit()，改用form.requestSubmit() - 如果需要在 JS 中主动提交（比如回车触发、按钮绑定非 submit 类型），只对
button绑定点击，内部调用form.requestSubmit() - 注意兼容性：
requestSubmit()在 Safari 15.4+、Chrome 88+、Firefox 89+ 支持；老版本需降级到dispatchEvent(new Event('submit', { cancelable: true }))
服务端没做幂等？前端禁用只是掩耳盗铃
前端禁用按钮只能减少重复提交概率，不能替代服务端防护。网络超时重试、刷新页面后重新提交、Post/Redirect/Get 模式异常，都可能绕过前端控制。
真正可靠的防线在后端：生成一次性 form.token，随表单下发，提交时校验并立即作废；或基于业务字段（如订单号+用户ID）做唯一索引约束。
- 前端可配合生成并携带
data-timestamp或data-nonce，但仅作辅助标记，不可作为唯一判断依据 - 若后端已支持
Idempotency-Key头，前端应在每次提交时生成 UUID 并透传，而不是复用旧值 - 别在 JS 里存“是否已提交”标志位来控制逻辑分支——页面刷新后状态丢失，反而造成不一致
移动端键盘回车误触提交怎么防
移动端软键盘的“搜索”“前往”“完成”等按钮，会默认触发表单提交，尤其在单输入框场景下极易误发。这不是 bug，是浏览器对 form 的语义化行为。
解决思路不是屏蔽回车，而是让回车行为可控：要么明确指向搜索逻辑，要么阻止默认提交。
- 给
input加type="search"，并监听input.search事件，配合event.preventDefault()阻止自动提交 - 如果表单确实只需一个输入框，考虑不用
form标签包裹，改用div+ 手动绑定事件，避免触发原生 submit 流程 - 不要依赖
onkeydown拦截Enter键码——不同输入法、系统、键盘布局下键码可能不一致，且破坏可访问性
disabled 就完事，它横跨 HTML 语义、事件机制、网络容错和服务端设计。最容易被忽略的是：把前端限制当最终防线，而忘了用户可以禁用 JS、绕过 DOM、甚至直接 curl 提交。 
