直接使用 html 的 disabled 属性是最可靠方式，它同时禁用鼠标、键盘交互并屏蔽屏幕阅读器误读，而仅靠 css 或错误的 js 赋值（如字符串）均不可靠，服务端也需同步控制。
按钮禁用后仍能被聚焦或键盘触发？
直接给 button 加 disabled 属性是最可靠的方式，它不仅视觉置灰、阻止鼠标点击，还会自动屏蔽键盘交互（如回车/空格触发）和屏幕阅读器误读。别用 pointer-events: none 或 user-select: none 替代——前者不阻断键盘，后者完全无效于按钮交互。
常见错误是只加 CSS：button { opacity: 0.5; cursor: not-allowed; }
这看起来“不可点”，但用户按空格键照样能提交，还可能被辅助工具识别为可操作控件。
- 必须用 HTML 属性：
<button disabled>加入购物车</button>
- 服务端渲染时，如果按钮状态动态变化，确保前后端都同步控制
disabled 属性，而非仅靠 JS 切换 class - 若需保留按钮样式（比如禁用时仍要显示 hover 效果），可用
:disabled伪类定制，例如：button:disabled { background: #ccc; }
JS 动态控制按钮禁用状态要注意什么？
用 JavaScript 控制 disabled 属性时，别写成 btn.setAttribute('disabled', 'true') 或 btn.disabled = 'true'——字符串值不会生效；正确写法是布尔赋值：btn.disabled = true 或 btn.removeAttribute('disabled')。
典型场景：库存为 0 时禁用按钮。注意不要只靠前端判断，否则用户改 DOM 就能绕过：
- 初始渲染时，服务端就该输出
disabled（如库存 ≤ 0） - JS 更新状态时，同步更新
btn.disabled = stock ，并重新设置 <code>aria-disabled="true"提升可访问性 - 避免在事件监听里用
event.preventDefault()拦截点击——这是补救措施，不是禁用逻辑
为什么加了 disabled 按钮的值不提交？
这是 HTML 表单规范行为：disabled 的表单控件（包括 button）在表单提交时会被忽略，其 name 和 value 不会出现在 POST 数据中。如果你需要“禁用但提交值”，说明设计有误——按钮本身不带业务数据，应由隐藏字段或接口参数承载上下文。
- 错误做法：
<button name="action" value="add" disabled></button>期待后端收到action=add - 正确做法：禁用按钮仅作 UI 反馈，实际提交靠表单其他字段或 API 调用，库存/规格等状态应在请求体中显式传参
- 若必须保留按钮参与提交（极少见），改用
readonly+ CSS 禁用外观，但需额外 JS 阻止点击，并手动处理可访问性
移动端 Safari 上 disabled 按钮偶尔还能点？
老版本 iOS Safari（≤14.5）存在 bug：对刚插入 DOM 的 disabled 按钮，首次触摸可能触发 click 事件。这不是样式问题，而是事件冒泡时机异常。
- 临时修复：插入按钮后，用
setTimeout(() => btn.disabled = true, 0)延迟设禁用 - 更稳妥方案：绑定
click事件时，第一行就检查if (this.disabled) return - 别依赖
touchstart阻止，因为 click 事件仍会冒泡上来
disabled 会影响表单数据提交逻辑——它只影响交互，不影响你该传什么。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
