css 伪类与元素状态控制_使用 :disabled 和 :enabled 控制按钮和表单元素的样式_技术教程

:disabled仅对原生支持disabled属性的表单元素（如button、input（除hidden）、select、textarea）生效；对div等不支持元素无效，需用class模拟，并注意可访问性与框架透传问题。

什么时候 `:disabled` 会生效？

它只对原生支持 disabled 属性的表单元素起作用，比如、（除 type="hidden" 外）、、。对 或自定义组件加 disabled 属性不会触发该伪类——浏览器根本不识别它的状态。

常见错误是给或封装后的 MyButton 组件加 disabled 属性却指望 :disabled 生效，结果样式毫无变化。此时必须用 JavaScript 手动加 class（如 .is-disabled）再写对应规则。


注意：HTML 中显式写 disabled（无值）或 disabled="" 效果一致；但 disabled="false" 依然算禁用——布尔属性只看是否存在，不看值。


:enabled 和 :not(:disabled) 不完全等价
:enabled 是语义化伪类，专指“可交互且未被禁用”的表单控件；而 :not(:disabled) 是逻辑取反，只要没写 disabled 属性就匹配，哪怕元素本身根本不支持该属性（比如 
），也会被选中。
这意味着：

对 ，两者表现一样
对 ，:not(:disabled) 仍会匹配它（因为 :disabled 对  无效，取反为真），但 :enabled 完全不匹配
对 ，:enabled 不匹配（规范明确排除 hidden 类型），但 :not(:disabled) 会匹配（因它没写 disabled）


所以，控制表单元素状态时优先用 :enabled 和 :disabled，别图省事用 :not() 替代。

样式覆盖与可访问性陷阱
仅靠视觉样式区分启用/禁用状态远远不够。屏幕阅读器依赖 disabled 属性本身来跳过控件，而不是 CSS 类。如果只改样式不设属性，键盘用户仍能 Tab 进去并触发事件，造成行为和视觉严重不一致。
正确做法始终是：

用原生 disabled 属性控制功能禁用
用 :disabled 伪类统一调整视觉（透明度、颜色、指针）
避免在 :disabled 规则里写 cursor: not-allowed 单独处理——它只是补充，不能替代 disabled 属性
禁用状态下移除 tabindex（原生 disabled 已自动处理这点，但手写 class 方式容易漏）

另外，不要用 opacity: 0.5 作为唯一禁用标识——低对比度可能违反 WCAG 文本可读性要求。建议搭配背景色、边框灰度、pointer-events: none（仅辅助，不能替代 disabled）一起用。

React/Vue 等框架中怎么安全使用？
框架组件常把 disabled 作为 prop 透传到原生子元素，但要注意是否真的落到最终 DOM 节点上。例如：
提交

如果 MyButton 内部没把 disabled 传给 ，那 :disabled 就不会生效。检查渲染后的 HTML，确认  存在。
常见疏漏点：

条件渲染时误写成 disabled={isSubmitting ? true : undefined} —— 应写成 {isSubmitting && 'disabled'} 或直接 disabled={isSubmitting}（JSX 中布尔值会自动转为属性存在/不存在）
服务端渲染（SSR）时，初始状态没同步 disabled 属性，导致首屏样式错乱
使用 CSS-in-JS（如 styled-components）时，忘记在底层组件中透传 disabled 属性，导致伪类失效

最稳妥的方式：始终让真实 DOM 元素承载 disabled 属性，CSS 伪类只负责响应它——别试图绕过 DOM 状态做样式判断。