原生表单控件必须用disabled属性，不可仅靠CSS类模拟；BEM修饰符如button--disabled仅适用于非原生组件或视觉补充，动态禁用应使用button--is-disabled并同步更新aria-disabled。
禁用状态该用 disabled 还是自定义类？
原生表单控件（<button>、<input>）必须用 disabled 属性，CSS 无法可靠模拟其语义和行为：屏幕阅读器会跳过它，键盘焦点不会进入，JS 的 click 事件也不会触发。BEM 修饰符如 button--disabled 只适合非原生组件（比如用 <div> 实现的按钮），或作为视觉降级的补充。
- 对
<button disabled>，直接写button:disabled { opacity: 0.4; cursor: not-allowed; }，别再加额外类 - 若组件封装了原生控件（如 React 的
Button组件），内部应透传disabled属性到真实 DOM 节点 - 用
button--disabled模拟禁用时，必须手动加tabindex="-1"和aria-disabled="true"，否则可聚焦却不可操作
BEM 修饰符命名要匹配交互逻辑，不是视觉状态
button--disabled 听起来像“当前禁用”，但实际它表达的是“这个按钮被设计为禁用态”，属于组件变体，不是运行时状态。真正需要响应式切换的，应该用 JS 控制类名增删，且修饰符名要体现控制意图，比如 button--is-disabled 或 button--state-disabled。
- 静态禁用（始终不可用）：用
button--disabled，编译时写死 - 动态禁用（由表单校验等控制）：用
button--is-disabled，JS 根据条件 toggle - 避免用
button--gray或button--faded这类纯视觉命名，后续换主题或改交互逻辑时极易脱节
激活态（active）容易和伪类 :active 冲突
CSS 中 :active 是用户按下鼠标/触摸屏时的瞬时状态，而 BEM 的激活态（如 tab--active）通常指当前选中项，是持久状态。两者共存时，样式优先级和覆盖逻辑容易出错。
- 不要用
tab--active覆盖:active的所有样式；分开处理：视觉选中用tab--active，按下反馈用tab:active - 如果组件需要“按住时也保持高亮”，得用 JS 切换
tab--is-pressed类，并在 CSS 中叠加：.tab--active.tab--is-pressed { ... } - 移动端要注意
:active默认不触发，需给<html>加ontouchstart=""或用pointer-events: none配合 JS 模拟
禁用 + 激活同时存在时，样式权重和可访问性要双重验证
比如一个已选中的 Tab 项被整体禁用（如权限不足），此时 tab--active 和 tab--is-disabled 同时存在。CSS 规则顺序、!important 使用、以及 aria 属性是否准确反映最终状态，三者缺一不可。
立即学习“前端免费学习笔记（深入）”；
- 禁用优先级应高于激活：写成
.tab--is-disabled.tab--active { opacity: 0.5; }，而不是反过来 - 必须设置
aria-disabled="true"，且移除aria-selected="true"—— 已禁用的项不能被视作“已选中” - 测试时用键盘 Tab 切换，确认禁用项完全跳过；用 VoiceOver/NVDA 朗读，确认听到的是“xxx，不可用”，而非“xxx，已选中”
最常漏掉的是 aria 属性与类名不同步，尤其在异步权限判断后只改了 class 却忘了更新 aria。
