该用 :disabled 伪类而非 disabled 属性本身来精准控制禁用态视觉样式。它仅匹配原生可禁用元素（如 button、input 等）且带 disabled 属性时的状态，优先级高、响应动态变更，但对 div 或自定义组件无效。
:disabled 而不是 disabled 属性本身？直接写 disabled 属性会让控件不可交互、不可聚焦、不提交值，但样式上默认灰掉——这不够灵活。:disabled 伪类才是真正控制「视觉反馈」的入口，它只在元素带有 disabled 属性时匹配，且优先级高于普通选择器，适合统一覆盖禁用态外观。
常见错误是以为加了 disabled 就自动有灰色效果，结果发现自定义组件（比如用 div 模拟的开关）没反应——因为 :disabled 只对原生可禁用元素生效（button、input、select、textarea、optgroup、option），对 div 或自定义 Web Component 无效。
disabled 属性才能触发 :disabled
fieldset 上设 disabled 会使其内部所有表单控件也进入禁用态，并被 :disabled 匹配disabled 属性会实时触发 :disabled 样式重绘
:enabled 的实际价值远不止“:disabled 的反义词”:enabled 匹配所有未被禁用的可交互表单元素，包括那些根本没设 disabled 属性的元素。它的关键用途是做「状态隔离」：比如你想让启用态的按钮有悬停效果，但禁用态完全不响应 :hover，这时写 button:enabled:hover 比写一堆 button:not(:disabled):hover 更清晰、更可靠。
注意：:enabled 对 input[type="hidden"]、input[type="reset"] 等本身不可交互的类型也返回 true——只要没加 disabled，它就认为“逻辑上可用”。所以别依赖它判断是否真能输入。
input[type="number"]:enabled 会匹配未禁用的数字输入框，但不会匹配 input[type="file"]:enabled（文件输入框即使未禁用，在某些浏览器中 hover 也不触发样式）:disabled 一样，:enabled 不作用于非表单元素，哪怕你给 div 加了 contenteditable="true"
:enabled:invalid 是比 :invalid:not(:disabled) 更简洁的写法button:disabled 有时不生效？检查这三点最常踩的坑是样式被覆盖或选择器不匹配。CSS 优先级、元素实际状态、以及伪类支持范围都可能让预期失效。
role="button" + aria-disabled="true"，但此时 :disabled 仍不生效，得用 [aria-disabled="true"]
button[disabled] 比 button:disabled 优先级略高（属性选择器 vs 伪类），建议统一用后者避免混淆fieldset:disabled 内部子元素的 :disabled 匹配有延迟，需强制重排或改用 JS 监听 fieldsets 的 disabled 变化button:disabled {
opacity: 0.5;
cursor: not-allowed;
background-color: #e0e0e0;
}
/ 避免这样写，容易漏掉动态添加 disabled 的情况 /
button[disabled] {
opacity: 0.5;
}
纯 CSS 无法监听状态变化，但 :disabled 和 :enabled 是 JS 控制 UI 反馈最轻量的搭档。重点不是“怎么加属性”，而是“加完后样式是否如预期更新”。
element.disabled = true 而不是 element.setAttribute('disabled', '')，前者更语义、兼容性更好fieldset 设 disabled 比遍历每个子控件更高效，且子控件自动获得 :disabled 匹配form.reset()）后，input 的 disabled 属性不会被还原——它只还原 value 和 checked，禁用状态需手动同步复杂点在于异步状态：比如按钮点击后禁用，等 API 返回再启用。这时候要确保禁用期间用户无法重复点击，且样式立刻响应——button:disabled 的样式切换是即时的，但 JS 中若忘记在 catch 里恢复 disabled = ，按钮就会永远卡住。
false