disabled是语义锁而非开关，设为true时按钮失去焦点、不响应click、不参与表单序列化且被屏幕阅读器跳过；必须用原生disabled属性，禁用时name/value不提交；type="submit"禁用无法阻止回车提交，需配合form.submit监听；disabled须在事件首行同步设置并finally恢复。
button 的 disabled 属性不是开关，而是语义锁
它不单是“让按钮点不了”，而是告诉浏览器：这个控件当前不属于交互流程的一部分。一旦设为 disabled，按钮立刻失去焦点能力、不响应 click、不参与表单数据序列化，且屏幕阅读器会跳过它——这是原生可访问性保障，不是 CSS 能模拟的。
常见错误是用 pointer-events: none 或 opacity: 0.5 伪装禁用状态，结果键盘用户仍能 Tab 进去按回车，读屏软件也播报“可点击”。真正禁用必须靠 disabled 属性本身。
-
disabled是布尔属性：存在即禁用，移除即启用；disabled="false"无效，照样禁用 - JS 控制时只用
btn.disabled = true或btn.disabled = false，别用setAttribute('disabled', ...) - 禁用按钮的
name和value不会随表单提交——这点常被忽略，尤其在多操作按钮（如type="submit" name="action" value="save"）场景下
type="submit" 按钮禁用后，为什么回车还能提交？
因为浏览器对 form 的回车提交行为，触发的是 submit 事件，不是 click 事件。而 disabled 只拦截鼠标/触屏点击和焦点交互，不阻止表单级提交流。
所以仅禁用 type="submit" 按钮，无法阻止用户在输入框里按回车触发表单提交。真正可靠的方案是监听 form.submit 事件统一控制：
form.addEventListener('submit', e => {
if (isSubmitting) {
e.preventDefault(); // 阻断默认提交
}
});- 若用
fetch或axios手动提交（非原生 form submit），回车根本不会触发，此时禁用按钮才真正生效 - 如果坚持用原生表单提交，
disabled必须配合form.submit监听，二者缺一不可 - 别指望
event.preventDefault()放在按钮click回调里——它拦不住回车
disabled 设置时机错，防重就形同虚设
用户快速连点两次，第一次请求还没发出去，第二次已进入事件回调——这就是竞态窗口。关键在于：disabled 必须在事件处理函数第一行同步设置，不能等异步操作开始后再设。
正确写法：
btn.addEventListener('click', () => {
btn.disabled = true; // ✅ 第一行就锁住
fetch('/api/submit')
.then(() => { /* 成功逻辑 */ })
.catch(() => { /* 失败也要恢复 */ })
.finally(() => { btn.disabled = false; });
});- ❌ 错误：把
btn.disabled = true写在fetch().then()里，或用setTimeout包裹 - ❌ 错误：只在成功路径恢复
disabled，失败后按钮永久锁定 - ✅ 必须在
finally或显式catch+then中恢复，覆盖所有退出路径
disabled 状态恢复时，别漏掉可访问性与视觉反馈
恢复 disabled = false 后，按钮只是“技术上可用”，但用户可能看不出变化——尤其当项目覆盖了默认样式。
必须手动确保：
- CSS 中定义
button:disabled样式，包括cursor: not-allowed和明显降权的背景/文字色 - 别用
aria-disabled覆盖原生disabled：两者共存时，部分读屏软件优先采信 ARIA，反而破坏语义 - 如果业务需要“加载中”状态（比如带旋转图标），优先用框架的
loading属性，而非混用disabled——后者会切断所有交互，包括 hover 效果和键盘反馈
最易被忽略的点：禁用状态不只是前端体验问题，它直接改变表单数据结构、影响可访问性链路、并和后端幂等设计强耦合。光加个 disabled，只是开了个门缝。
