button标签本质是语义化可交互控件，原生支持表单提交、重置、禁用、键盘焦点及屏幕阅读器播报；禁用按钮不能阻止回车触发表单提交，需统一监听form.submit事件或使用type="submit"配合disabled，且disabled必须在事件回调首行同步设置并覆盖成功与失败路径，前端防重仅为体验层防护，后端须配合幂等机制。
button 标签本质是语义化可交互控件，不是“用来触发 JS 的容器”——它原生支持表单提交、重置、禁用、键盘焦点、屏幕阅读器播报等行为。防重复点击不是给按钮加个 disabled 就完事，而是要对齐它的语义职责和真实交互链路。
button 禁用后为什么还能回车提交？
因为 button 的禁用（disabled）只影响鼠标点击和触屏 tap，但不拦截表单的 submit 事件——尤其是用户在输入框内按回车时，浏览器会自动触发表单提交，完全绕过按钮状态。
- 只禁用
button不等于禁用表单提交，必须监听form.submit事件统一处理 - 若用
fetch或axios手动提交，回车不会触发，此时禁用按钮才真正有效 - 用
type="submit"的button时，禁用它确实能阻止回车提交；但用type="button"+onclick则完全无效
disabled 属性该在哪个时机设置？
必须在事件回调函数入口处同步设置，不能放在异步操作内部或延时之后。否则存在竞态窗口：用户快速连点两次，第一次还没来得及设 disabled，第二次就已进入函数体。
- ✅ 正确：
btn.disabled = true放在addEventListener回调第一行 - ❌ 错误：放在
fetch().then()里，或用setTimeout包裹后再设 - 恢复
disabled不能只靠成功路径，失败时也必须手动重置，否则按钮永久锁定
节流 throttle 和布尔锁的区别在哪？
节流（如 throttle(handleClick, 1000)）控制的是“单位时间内最多执行一次”，而布尔锁（if (isPending) return）控制的是“当前操作未结束前禁止下一次”。两者解决的问题维度不同。
立即学习“前端免费学习笔记（深入）”；
- 节流适合防抖式高频点击（比如搜索框的实时查询），但无法保证异步操作完成前不被再次触发
- 布尔锁更贴近业务逻辑，但需严格管理状态生命周期：Promise reject、网络超时、用户取消都得重置
- 节流不改变按钮 UI 状态，用户看不到反馈；布尔锁配合
disabled才有明确视觉阻断
为什么仅前端防重永远不够？
因为 disabled 可被绕过：禁用属性能被开发者工具直接删掉，click 事件能用 dispatchEvent 模拟，甚至 curl 直接发请求。服务端没有幂等校验，前端所有防护都是纸糊的。
- 前端做的是体验层防御：防止误点、提供即时反馈、减少无谓请求
- 后端必须配合一次性 token（如
submit_token）、Idempotency-Key头，或数据库唯一约束 - 最稳妥的是 PRG 模式（POST-Redirect-GET）：提交成功后 302 跳转，F5 刷新的是结果页而非重复 POST
真正难的不是让按钮“看起来不能点”，而是让它在各种输入方式（键盘回车、触屏、辅助技术）、各种失败路径（网络中断、服务端报错、用户中途关闭页面）下，状态始终可预测、可恢复。按钮稳不稳，不在样式，而在状态是否与真实业务生命周期对齐。
