:enabled 伪类仅匹配原生支持 disabled 属性的表单控件（如 、 等），不作用于 或自定义组件；常见失效原因包括视觉模拟禁用、JS 未同步设置 DOM 属性、框架中响应式变量未正确渲染 disabled 属性。
`:enabled` 伪类匹配哪些元素
它只作用于**原生支持 disabled 属性的表单控件**，比如 <input>、<select></select>、<textarea></textarea>、<button></button>、<optgroup></optgroup>。不是所有带 disabled 的标签都算——比如 <div disabled> 或自定义组件加了 <code>disabled 属性，:enabled 完全不生效。
常见误判：以为给任意元素加 disabled 就能被 :enabled 捕获。其实浏览器只认语义化表单控件的原生禁用逻辑。
为什么 :enabled 不生效的几个典型原因
最常踩的坑是混淆了「视觉禁用」和「真实禁用」：
- 用了
pointer-events: none+opacity: 0.5模拟禁用，但元素没加disabled属性 →:enabled不触发 - 通过 JS 动态设置
element.disabled = true，但忘了同步更新 DOM 属性（例如没调用el.setAttribute('disabled', '')）→ 部分旧版 Safari 可能不识别 - 在 Vue/React 中用
:disabled="flag"渲染，但 flag 是响应式变量且初始为undefined→ 实际没渲染出disabled属性，:enabled默认命中
:enabled 和 :not(:disabled) 有区别吗
理论上等价，但实际行为略有差异：
立即学习“前端免费学习笔记（深入）”；
-
:enabled是专用于表单控件的语义伪类，语义清晰，可读性好 -
:not(:disabled)在某些老浏览器（如 IE11）中对<option></option>元素支持不稳定；另外如果元素本身不支持disabled（比如<p></p>），:not(:disabled)会意外匹配，而:enabled完全不匹配 - 性能上无明显差别，现代浏览器都做了优化，但建议优先用
:enabled—— 更准确，也更不容易写出“假禁用”逻辑
配合 :focus 或 :hover 使用时要注意什么
组合伪类顺序影响样式优先级和可访问性：
- 写成
input:enabled:hover没问题，但input:hover:enabled在部分浏览器里可能不生效（伪类顺序敏感） - 如果同时写了
input:enabled:focus和input:focus，后者权重更低，会被覆盖；但若用户用键盘 tab 进入，而该元素恰好被 JS 设为disabled，焦点还在但:enabled不匹配 → 此时:focus样式就失效了 - 移动端 Safari 对
:enabled:focus支持较弱，建议加一层.focus-visible回退逻辑，或用 JS 监听focusin动态加 class
真正容易被忽略的是：禁用状态切换后，焦点不会自动离开元素。用户 tab 进去再按 tab，焦点可能卡在 disabled 元素上（尤其在无障碍场景下），这时仅靠 CSS 无法修复，得配 JS 处理焦点转移。
