在前端样式开发中，一个常见的设计模式挑战是如何有效管理组件的交互状态。当 BEM 方法论与 CSS 伪类相遇时，许多开发者容易陷入一个误区：将 :hover 或 :active 这类瞬时交互状态直接映射为类似 .btn--hover 的 BEM 修饰符。表面上看这种做法简单直接，实则隐藏着不少长期维护的隐患。
为何不应将 :hover 和 :active 直接映射为 BEM 修饰符
直接创建 .btn--hover 或 .btn--active 这类修饰符之所以被视为反模式，根源在于 BEM 修饰符与 CSS 伪类的本质用途截然不同。BEM 修饰符设计的初衷是描述组件的“静态变体”或“可编程状态”，例如 --disabled、--loading 或 --primary。相反，:hover 和 :active 是浏览器原生触发的瞬时交互状态，它们不受 JavaScript 直接控制，无法被序列化，也极难在自动化测试中稳定捕获。
这种混淆会引发一系列令人头疼的问题：
- 当元素被添加了
btn--hover类，但鼠标并未悬停时，样式却一直生效，导致 UI 状态与实际交互脱节。 - 对于使用键盘导航的用户，当他们通过 Tab 键聚焦到按钮时，
btn--hover样式完全不起作用，破坏了无障碍体验的完整性。 - 在 Jest 等测试环境中，为了模拟悬停行为，开发者不得不手动 mock
dispatchEvent，不仅成本高昂，还容易遗漏覆盖。
那么，正确的做法是什么？其实原则很简单：各司其职。将视觉反馈的逻辑交给 CSS 伪类，而将那些需要程序控制的“可控状态”留给 BEM 修饰符。
- 使用
.btn:hover来定义悬停时的视觉效果，例如颜色变化、阴影或轻微的位移。 - 使用
.btn:active来定义按下瞬间的反馈，比如缩放效果或背景色加深。 - 对于禁用状态，可以通过
.btn--disabled:hover显式覆盖，移除悬停效果。 - 而像
.btn--loading这样的修饰符，只负责管理加载图标、文字替换或pointer-events属性，不应干涉:hover的底层逻辑。
需要 JavaScript 控制的“悬停态”该使用什么修饰符
当然，业务场景中确实存在需要 JavaScript 介入的“悬停”逻辑。例如，某个卡片的悬停效果在用户权限关闭后需要完全消失，或者在特定的编辑模式下需要禁止所有交互反馈。此时，才应当考虑引入修饰符。
关键在于，修饰符的命名不应直接描述条件（如 --hover），而应描述结果或能力。举例来说：
.card--elevated：表示卡片当前处于“已提升”的视觉状态，该状态可能由鼠标悬停、键盘聚焦触发，也可能是由 JavaScript 主动设置。.card--interactive：表示组件整体支持交互（由权限或模式决定），它会间接影响:hover等伪类是否生效。.btn--no-interaction：相比--disabled更轻量，它可能只移除了视觉反馈，而不会阻断表单提交等核心功能。
这里有几个关键点需要把握：
- 修饰符必须能够独立存在。也就是说，当你移除这个修饰符类时，UI 应该能立刻回退到默认状态。
- 状态管理应由 JavaScript 统一处理，通过增删类来实现，而不依赖于具体的事件类型（无论是
mouseenter还是focus，都触发同一个 class 的变化）。 - 在 CSS 中，应直接定义
.card--elevated的最终样式，而不是写.card--elevated:hover这类组合，后者会模糊状态管理的边界。
如何让修饰符同时响应鼠标和键盘焦点
实现一个既能响应鼠标悬停，又能照顾键盘焦点状态的交互，是提升无障碍体验的关键。纯 CSS 很难可靠地判断“当前元素是否被聚焦且未被悬停”这种复合状态，因此需要 JavaScript 来协调。
核心思路不是创建两套独立的类，而是建立一个统一的状态入口，并分层响应事件。以下是一些实操建议：
- 为交互元素添加
tabindex="0"，确保其可以通过键盘聚焦。 - 同时监听
mouseenter/mouseleave和focus/blur事件。 - 在移除状态类（如
card--elevated）前，利用element.matches(':hover')和document.hasFocus()等方法判断状态是否应该保留。 - 避免在
mouseleave事件中立即移除类，可以首先检查元素是否仍然处于聚焦状态：card.addEventListener('mouselea ve', () => { if (!card.matches(':focus')) { card.classList.remove('card--elevated'); } });
通过这样的协调，既能兼容鼠标操作，又不会打断键盘用户的导航流，同时还能让屏幕阅读器正确地播报状态变化。
BEM 修饰符与伪类共存时的样式优先级陷阱
即使我们明确了分工，在具体编写样式时，另一个陷阱依然在等着我们：样式优先级。很多人会这样写：.btn--primary:hover，本意可能是想定义一个主题色按钮的悬停态。但这实际上埋下了三个隐患：
- 复用困难：违背了 BEM 希望样式可组合的初衷。如果另一个链接组件也需要主色调悬停效果，你就得重写一遍
.link--primary:hover。 - 权重失控：如果基础样式
.btn:hover在样式表中声明得更靠后，那么.btn--primary:hover的样式可能会被意外覆盖，导致调试困难。 - 语义混淆：
--primary本意是定义颜色主题，属于静态外观。将其与交互状态:hover混合，容易让团队成员误解设计意图。
更可持续的做法是坚持分离关注点：
- 让修饰符只管静态外观：
.btn--primary { background-color: #007bff; } - 让伪类统一接管交互反馈：
.btn:hover { transform: translateY(-2px); } - 例外覆盖只在绝对必要时进行：
.btn--disabled:hover { cursor: not-allowed; }
最后，还有一个极易被忽略的边界情况：当你开始使用 JavaScript 来控制像 --elevated 这类修饰符时，必须同步考虑触摸设备。这意味着你需要处理 touchstart 和 touchend 事件，否则移动端用户会感觉点击“没有反应”。这个层面的交互协调，是纯 CSS 伪类无法自动覆盖的，必须在设计交互逻辑时就纳入考量。
