按钮设disabled却仍可点击或表单照常提交，根本原因是未正确理解disabled是“语义锁”而非“视觉锁”：必须用button.disabled=true/false操作，配合button:disabled样式、form.submit拦截及name/value不提交等规范，否则交互、无障碍与数据流均会出错。
按钮设了 disabled 却还能点，或者点了没反应但表单照样提交——这不是浏览器 bug，而是对 disabled 的语义和边界理解有偏差。它不是“视觉锁”，而是“语义锁”，必须按规范用，否则交互、可访问性、数据提交全会出问题。
button.disabled = true 是禁用，不是“启用”
最常见翻车点：把布尔逻辑写反。比如输入框有内容时想启用按钮，却写了 btn.disabled = input.value !== ''，结果一输内容按钮立刻变灰。正确映射是“无效 → 禁用，有效 → 启用”：
-
btn.disabled = input.value.trim() === ''—— 一行搞定校验+赋值 - 别写
btn.setAttribute('disabled', 'false')，哪怕值是false，只要属性存在，就禁用 -
btn.disabled = false才是启用；btn.removeAttribute('disabled')也行，但不如直接赋布尔值可靠
input 事件比 onkeyup 更靠谱
只监听 onkeyup 会漏掉粘贴、自动填充、语音输入等场景，按钮状态卡死。必须用 input 事件：
-
input覆盖所有值变更路径（包括剪切、撤销、密码管理器填充） - DOM 加载完必须立即执行一次校验，否则预填充内容不会触发事件，按钮初始状态错误
- 动态插入的按钮（如 Vue/React 渲染或 AJAX 加载），要先判空：
if (!btn) return，再操作disabled
type="submit" 按钮禁用后，回车仍能提交
这是 disabled 的明确边界：它只拦截 click 和焦点交互，不阻止表单级 submit 事件。用户在输入框里按回车，照样触发表单提交。
- 解决方案不是加
event.preventDefault()在按钮上，而是监听整个form的submit事件 - 在
form.addEventListener('submit', e => { if (btn.disabled) e.preventDefault(); })中做判断 - 注意：禁用的
button[type="submit"]的name/value不会随表单提交——这点常被忽略，尤其当后端靠action=save区分操作类型时
:disabled 伪类必须配合 cursor 和 opacity 显式声明
浏览器默认禁用样式不可靠，尤其在重置 CSS 或自定义主题时。仅靠 disabled 属性不保证视觉反馈：
- 必须写
button:disabled { cursor: not-allowed; opacity: 0.6; }，否则鼠标悬停无提示 - 避免同时用
aria-disabled="true"和原生disabled，读屏软件可能优先采信 ARIA，反而覆盖原生语义 - 禁用按钮的
name和value不参与序列化——这是 HTML 规范行为，不是 bug，后端不能假设它一定存在
真正麻烦的从来不是怎么写 disabled，而是它背后牵扯的三件事：表单数据流是否干净、键盘用户能否绕过、屏幕阅读器播报是否准确。漏掉任意一环，都算没禁用成功。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
