:disabled仅对原生支持disabled属性的表单元素（如button、input（除hidden）、select、textarea）生效；对div等不支持元素无效，需用class模拟，并注意可访问性与框架透传问题。
什么时候 :disabled 会生效？
它只对原生支持 disabled 属性的表单元素起作用，比如 <button></button>、<input>（除 type="hidden" 外）、<select></select>、<textarea></textarea>。对 <div> 或自定义组件加 <code>disabled 属性不会触发该伪类——浏览器根本不识别它的状态。
常见错误是给 <span></span> 或封装后的 MyButton 组件加 disabled 属性却指望 :disabled 生效，结果样式毫无变化。此时必须用 JavaScript 手动加 class（如 .is-disabled）再写对应规则。
注意：HTML 中显式写 disabled（无值）或 disabled="" 效果一致；但 disabled="false" 依然算禁用——布尔属性只看是否存在，不看值。
:enabled 和 :not(:disabled) 不完全等价
:enabled 是语义化伪类，专指“可交互且未被禁用”的表单控件；而 :not(:disabled) 是逻辑取反，只要没写 disabled 属性就匹配，哪怕元素本身根本不支持该属性（比如 <p></p>），也会被选中。
立即学习“前端免费学习笔记（深入）”；
这意味着：
- 对
<input type="text">，两者表现一样 - 对
<div disabled>，<code>:not(:disabled)仍会匹配它（因为:disabled对<div> 无效，取反为真），但 <code>:enabled完全不匹配 - 对
<input type="hidden">，:enabled不匹配（规范明确排除 hidden 类型），但:not(:disabled)会匹配（因它没写disabled） - 用原生
disabled属性控制功能禁用 - 用
:disabled伪类统一调整视觉（透明度、颜色、指针） - 避免在
:disabled规则里写cursor: not-allowed单独处理——它只是补充，不能替代disabled属性 - 禁用状态下移除
tabindex（原生disabled已自动处理这点，但手写 class 方式容易漏）
所以，控制表单元素状态时优先用 :enabled 和 :disabled，别图省事用 :not() 替代。
样式覆盖与可访问性陷阱
仅靠视觉样式区分启用/禁用状态远远不够。屏幕阅读器依赖 disabled 属性本身来跳过控件，而不是 CSS 类。如果只改样式不设属性，键盘用户仍能 Tab 进去并触发事件，造成行为和视觉严重不一致。
正确做法始终是：
另外，不要用 opacity: 0.5 作为唯一禁用标识——低对比度可能违反 WCAG 文本可读性要求。建议搭配背景色、边框灰度、pointer-events: none（仅辅助，不能替代 disabled）一起用。
React/Vue 等框架中怎么安全使用？
框架组件常把 disabled 作为 prop 透传到原生子元素，但要注意是否真的落到最终 DOM 节点上。例如：
<MyButton disabled={isSubmitting}>提交</MyButton>
如果 MyButton 内部没把 disabled 传给 <button></button>，那 :disabled 就不会生效。检查渲染后的 HTML，确认 <button disabled></button> 存在。
常见疏漏点：
- 条件渲染时误写成
disabled={isSubmitting ? true : undefined}—— 应写成{isSubmitting && 'disabled'}或直接disabled={isSubmitting}（JSX 中布尔值会自动转为属性存在/不存在） - 服务端渲染（SSR）时，初始状态没同步
disabled属性，导致首屏样式错乱 - 使用 CSS-in-JS（如 styled-components）时，忘记在底层组件中透传
disabled属性，导致伪类失效
最稳妥的方式：始终让真实 DOM 元素承载 disabled 属性，CSS 伪类只负责响应它——别试图绕过 DOM 状态做样式判断。
