CSS项目命名规范：BEM框架应用指南

本文深入解析了BEM命名规范的核心价值与实践要义，强调其并非表面的“命名风格”，而是保障样式作用域解耦、降低DOM重构风险的关键工程约束：双下划线（__）强制表达元素对区块的强归属，短横线（--）修饰符必须锚定于具体主体，任何随意替换或省略都会破坏语义层级、引发样式冲突与维护陷阱；同时指出BEM落地需紧扣HTML结构本质、审慎兼容第三方库，并坦诚揭示其适用边界——在超小粒度组件、CSS-in-JS环境或成熟替代方案已就位时，盲目套用反而得不偿失；真正考验团队的，是每一次添加class前对“可读性”与“可维护性”的清醒判断。

为什么 BEM 的 block__element--modifier 结构不能乱改

BEM 不是命名“风格”，而是为了解耦样式作用域和 DOM 变更成本。一旦把 __ 写成 - 或删掉双下划线，CSS 选择器就失去语义层级，.btn-primary 和 .btn__primary 在组件重构时表现完全不同。

• block__element 表示强归属关系：这个 element 只在 block 内部有意义，移出去就失效
• --modifier 必须作用于 block 或 element 本身，不能单独存在，否则无法通过 class 切换状态
• 用 btn-large 替代 btn--large 会导致和 btn__icon--large 冲突，失去修饰目标锚点

HTML 中怎么写才不破坏 BEM 语义

关键不是“有没有双下划线”，而是 class 是否真实反映 DOM 结构层级。BEM 要求每个 class 只表达一个角色：要么是 block，要么是它的 element，要么是它的 modifier。

• 禁止嵌套 block：
  …
  —— button 是独立 block，不是 card 的 part
• element 必须直属于 block：
  ✅；

  ❌（不存在 __header__ 这种三级）

• modifier 永远附加在主体 class 后：class="card card--featured" 或 class="card__body card__body--compact"，不能写成 card-featured__body

遇到第三方组件库（如 Ant Design）怎么兼容 BEM

不要强行给第三方 class 改名或加 BEM 前缀。它们的 class 是封装好的实现细节，硬套 BEM 只会让维护更糟。

• 用 wrapper 元素隔离：
  ，只对 wrapper 应用 BEM
• 覆盖样式时用 BEM 规则写 CSS，但 selector 目标仍是第三方 class：.my-form .ant-select-selector { … }，而非试图重写 .ant-select-selector 为 .my-form__select
• 如果必须复刻 UI，就新建纯 BEM 组件，别在第三方 class 上叠 layer

什么时候该放弃 BEM，而不是硬套

BEM 在中大型项目里降低协作成本，但它不是银弹。当出现这些信号，说明当前场景不适合：

• 组件粒度极小且无复用（比如一页只有一个 hero-banner），加 hero-banner__title 反而增加认知负担
• 使用 CSS-in-JS（如 styled-components），天然靠 JS 作用域隔离，const Title = styled.h1 已隐含归属关系
• 团队已稳定使用其他约定（如 SUIT CSS），强行切换带来的沟通成本 > 命名混乱成本

真正难的不是记住 __ 和 --，而是每次加 class 前问一句：这个 class 是为了让人一眼看懂结构，还是为了方便 grep 替换？后者往往埋雷。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《CSS项目命名规范：BEM框架应用指南》文章吧，也可关注golang学习网公众号了解相关技术文章。