submit事件中禁用按钮失效是因为form.submit()不触发submit事件，绕过事件监听；应将禁用逻辑提前至click事件或统一提交入口，并配合服务端防重机制。
submit事件里禁用按钮为什么有时失效
因为 form.submit() 方法调用不会触发 submit 事件，而很多 UI 库、表单校验逻辑或手动提交代码里会直接调用它。如果你只把 btn.disabled = true 写在 addEventListener('submit', ...) 里，这部分逻辑就完全被绕过了。
真正可靠的写法是：把禁用逻辑**提前到按钮的 click 事件里**，或者**同时覆盖 form.submit 方法**（不推荐复杂项目用）。更稳妥的做法是统一入口——所有提交都走同一个函数，里面先禁用再发请求。
- 监听
button[type="submit"]的click，立即设disabled = true，再调用form.submit()或event.preventDefault()后走 fetch - 如果页面存在多个提交按钮（如“保存”“保存并新建”），必须批量禁用：
form.querySelectorAll('button[type="submit"], input[type="submit"]') - 别写
onsubmit="this.disabled=true"——this指的是form元素，不是按钮，会报错
disabled 属性加在哪儿才真正起作用
disabled 只对原生表单控件生效：button、input（含 type="submit"）、select、textarea、fieldset。给 div、span、label 加 disabled 属性完全无效，浏览器直接忽略。
特别注意：fieldset 是少数能“递归禁用”子元素的容器。用它包裹整个表单区域，比逐个控制按钮更省事，但要注意嵌套 fieldset 时内层 disabled 不会覆盖外层状态。
- 禁用单个按钮：
<button type="submit" disabled>提交</button>（静态）或btn.disabled = true（动态） - 禁用整组控件：
<fieldset disabled> <input><select><button></button></select> </fieldset> - 别试图给
form标签加disabled—— HTML 规范不支持，无效
为什么禁用按钮后仍可能重复提交
用户按回车键触发表单提交时，根本没点按钮，click 事件不触发；submit 事件虽然触发了，但如果禁用逻辑只写在 click 里，照样白搭。更隐蔽的是：禁用按钮后，用户刷新页面再提交，前端毫无感知。
所以仅靠 disabled 是障眼法。它解决的是“肉眼可见的连点”，不是“逻辑上的重复”。真正防重必须靠服务端一次性 token + 明确消费标记。
- 回车提交、JS 手动调用
form.submit()、刷新后重发，都会绕过前端按钮禁用 -
disabled后的按钮值不会随表单提交，但表单其他字段照常发送 —— 这不是 bug，是规范行为 - 如果用了
fetch提交，记得在catch里恢复按钮（或提供重试机制），不能只在finally里无条件恢复
表单提交后要不要自动恢复按钮状态
不要自动恢复。用户看到按钮变灰，以为操作成功了；如果后端失败了，按钮却自己变回可点击，容易造成误操作。恢复动作必须由 JS 显式控制，且只在明确知道失败原因、允许重试时才做。
常见错误是把 btn.disabled = false 放在 fetch().finally(...) 里——网络超时、服务不可用、甚至 CORS 错误都会触发 finally，结果按钮提前可用，用户可能填着旧数据又点一次。
- 成功时：跳转页面 or 渲染成功态，无需恢复按钮
- 失败时：根据响应状态码判断是否可重试（比如 400 字段错误可改后重试，500 或 token 失效应提示刷新）
- 加载中状态建议用 class 控制（如
btn.classList.add('loading')），比纯disabled更利于样式和无障碍支持
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
