:disabled伪类仅匹配原生表单控件的disabled属性，不支持div等非表单元素或aria-disabled；需用class模拟非表单禁用，并配合tabindex="-1"和aria-disabled="true"保障可访问性。
disabled 属性的 CSS 选择器怎么写
直接用 :disabled 伪类即可匹配原生表单控件（<button></button>、<input>、<select></select>、<textarea></textarea>）上设置了 disabled 属性的元素。它只响应 HTML 层面的 disabled 属性，不识别 aria-disabled="true" 或 class 模拟禁用状态。
常见错误是试图用 [disabled] 属性选择器替代 —— 虽然能选中，但语义和可访问性支持远不如 :disabled，且部分浏览器对 [disabled] 的样式优先级处理不稳定。
button:disabled {
opacity: 0.5;
cursor: not-allowed;
background-color: #e0e0e0;
}
为什么 div 或自定义组件加 disabled 不生效
:disabled 是**仅限表单控件**的伪类，<div disabled>、<code><span disabled></span> 这类写法在 HTML 中无效，浏览器会忽略该属性，:disabled 自然无法匹配。
若需为非表单元素实现禁用样式，必须改用 class 控制：
立即学习“前端免费学习笔记（深入）”；
- 手动添加
class="is-disabled"，再写.is-disabled { ... } - 配合 JavaScript 切换 class，同时设置
tabindex="-1"和aria-disabled="true"保证可访问性 - 避免仅靠视觉样式，否则屏幕阅读器仍会将其当作可交互元素
:disabled 与 :read-only、:read-write 的区别
三者作用对象和触发条件完全不同：
-
:disabled：只匹配带disabled属性的表单控件，完全不可交互、不提交、不获取焦点 -
:read-only：匹配readonly属性或contenteditable="false"的元素，内容不可编辑但可聚焦、可选中、可复制 -
:read-write：匹配可编辑状态（如contenteditable="true"或无readonly/disabled的<input>），常用于高亮当前可编辑区域
混淆使用会导致样式错位。例如给 input[readonly] 写 :disabled 样式，实际不会生效。
React/Vue 中动态控制 :disabled 样式要注意什么
框架里常通过绑定 disabled prop 控制状态，但容易忽略两点：
- 布尔 prop 传
false时，HTML 属性可能被完全省略（如 React 中<button disabled></button>不渲染disabled属性），此时:disabled不会触发 —— 必须确保禁用时属性存在，启用时移除 - 服务端渲染（SSR）场景下，若初始状态没正确同步
disabled属性，首屏样式可能与 JS 激活后不一致 - 不要依赖
className切换来模拟:disabled行为，否则键盘操作（如 Tab 键导航）仍会进入该元素
禁用状态的核心不是“看起来灰”，而是“行为和语义都断开”。样式只是表层反馈，属性、焦点、可访问性属性缺一不可。
