BEM规范如何清晰定义CSS组件层级

常见错误现象：

• 写

  …

  ，但漏掉 card__body，导致后续想加 body 样式时不敢动 card__title 的 margin
• 用 card__title card__subtitle 这种“复用类名”方式，破坏了 BEM 的唯一性原则，让 card__subtitle 失去独立样式控制能力

正确示例：

<article class="card">
  <header class="card__header">
    <h2 class="card__title">标题</h2>
  </header>
  <div class="card__body">内容区</div>
  <footer class="card__footer">操作按钮</footer>
</article>

遇到伪元素或状态类（:hover, :disabled）怎么处理

BEM 不排斥 CSS 状态伪类，但禁止用它们替代语义类名。比如不能靠 .card:hover .card__title 控制悬停变色，而应提前定义 card__title--hovered 并由 JS 切换。

原因很实际：

• CSS 无法在伪类中触发 transition 的 class 切换，容易造成动画卡顿
• 服务端渲染或 SSR 场景下，:hover 无法预判，样式不可控
• 可访问性工具（如屏幕阅读器）通常不识别伪类状态，而 card__title--focused 可以配合 tabindex 和 JS 显式管理

性能提示：大量使用 :not() 或 :has() 会显著拖慢重排，BEM 的扁平类名天生规避这类问题。

和 CSS-in-JS 或原子化方案（Tailwind）混用时要注意什么

可以共存，但边界必须清晰。BEM 负责语义层级和组件契约，其他方案负责视觉细节。

容易踩的坑：

• 在 React 中用 clsx 拼接 card__title 和 text-lg font-bold，结果 text-lg 覆盖了 card__title 的行高设定，且无法从组件层追溯
• 用 Tailwind 的 group-hover: 去驱动 card__title 变色，绕过了 BEM 的状态命名，导致同一组件在不同框架中行为不一致

推荐做法：BEM 类名只出现在 className 的最左侧，原子类放右侧，例如 className="card__title text-base group-hover:text-blue-600"，并确保 card__title 自身已定义基础排版（padding、line-height 等）。

真正麻烦的是跨团队协作时，有人坚持“BEM 只写结构”，有人默认“BEM + Tailwind = 全能”，没人管 card__title 的字体大小到底该谁定——这个边界不写进 README，三个月后就会变成玄学。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~