BEM：让CSS选择器自己开口说话
在CSS开发中，如何为类名（class）命名一直是个令人困扰的难题。但有一种方法论，能让你的class名像一份清晰的说明书——这就是BEM。它通过一套“块（Block）__元素（Element）--修饰符（Modifier）”的命名规则，让每个选择器的职责一目了然。例如，button__icon 直接表明这是按钮内部的图标元素，而 button--primary 则清晰地指出这是一个主色调的按钮变体。这套方法的核心价值在于，命名本身就能完整描述UI组件的逻辑结构与状态，无需开发者依赖上下文或额外的注释去猜测其含义。
为什么BEM能让人一眼看懂class名在干啥
其秘诀就在于它严格且直观的“三段式”结构。BEM使用固定的分隔符，将「组件块名」、「内部子元素」和「修饰状态」这三者清晰地区分开来。因此，当看到 header__logo--dark 这个类名时，即便不查看HTML源码，你也能立刻解读出：这是 header 组件块内的 logo 子元素，并且当前处于暗色模式的状态。
当然，在实践中总会出现一些常见的“跑偏”写法。例如写成 header-logo-dark，这混淆了分隔符，完全丢失了BEM的语义层次感。或者使用驼峰命名 headerLogoDark，不仅破坏了CSS选择器的可读性，也与前端社区的常规风格格格不入。另一个更隐蔽的陷阱是嵌套过深，例如 card__content__title__link —— BEM规范明确禁止出现三级及以上的子元素。遇到这种情况，通常意味着 title 本身应该被设计成一个独立的块（Block），正确的写法应该是 title__link。
- 子元素（Element）的标识是双下划线
__（例如button__icon），务必注意不是单下划线。 - 修饰符（Modifier）的标识是双短横
--（例如button--primary），切勿使用单个-或下划线_代替。 - 绝对不允许跨块组合类名。避免写出
header__button--submit这样的东西；如果button是一个独立组件，就应该直接使用button button--submit的组合。
怎么给一个按钮组件写合规的BEM class名
让我们从一个真实的开发场景入手：你需要封装一个可复用的按钮组件，它需要包含图标、支持加载状态，并且能够切换主题色和尺寸。BEM的核心原则之一是“一个class只负责一件事”，因此我们需要将不同维度的样式拆解成多个独立的类，而不是把所有语义都堆砌在一个冗长的类名里。
来看一个符合BEM规范的正确示例：。在这里，button 是基础块（Block），button--primary 和 button--large 是分别控制颜色主题和尺寸大小的修饰符（Modifier）。而 is-loading 则是一种常见的布尔状态类（在BEM社区中，通常推荐使用 is-、has- 这类前缀来表示动态的开关状态）。
立即学习“前端免费学习笔记（深入）”；
button__icon和button__text这类元素类，必须是块的直接子元素。不要在它们外面再额外包裹一层div并给这个div添加类名。- 不同的修饰符之间应该是正交的，可以自由组合使用。例如
button--primary button--small可以同时生效，互不影响。 - 避免创造类似
button--primary--loading这种复合修饰符。加载态（loading）应该由独立的is-loading类来控制，这样逻辑更清晰，也便于维护。
遇到第三方UI库时BEM怎么不打架
直接上手覆盖第三方组件库自带的class样式，无异于给自己埋下技术债务的隐患。BEM对此的推荐解决方案是“作用域隔离”：用一个我们自定义的BEM块作为容器，包裹住第三方组件，所有定制样式都通过这个容器块的选择器向下穿透控制，绝不直接修改或覆盖第三方组件的原始类名。
举个例子，在使用Element Plus的 el-button 组件时，不要直接写 .el-button--primary { ... } 去覆盖其原生样式。正确的做法是：.my-form__submit ::v-deep .el-button { ... }（Vue单文件组件中的深度选择器写法）或 .my-form__submit .el-button（常规CSS写法）来定义定制样式。这样既保持了项目自身的BEM结构清晰，又不会污染全局样式或与库的更新产生冲突。
- 应将第三方组件的原始class视为其内部实现细节，我们只通过外层BEM容器的选择器去约束它，绝不直接重写。
- 如果需要对组件内部深层结构进行定制（例如修改输入框的前缀图标），应优先使用组件库本身提供的插槽机制（如
prefix-icon），而不是强行给其内部元素（如el-input__inner）添加样式。 - 需要注意，如果项目同时使用了CSS-in-JS库（如Styled-components），其自动生成哈希class名的行为可能会破坏BEM的命名结构。此时需要配置类似
generateScopedName的选项，确保分隔符__和--得以保留。
为什么CSS Modules + BEM不是最佳拍档
问题的根源在于两者的默认行为存在冲突。CSS Modules 为了实现样式隔离，默认会给编译后的class名加上唯一的哈希后缀。于是，源代码中清晰的 button__icon 在DOM中可能就变成了 abc123__icon。这样一来，BEM精心构建的、具有高度可读性的语义链就在运行时“消失”了。开发者在调试时，无法将浏览器中看到的类名与源代码中的类名对应起来，设计师在标注稿上写的类名也变得无从查找。
如果非要将两者结合使用，就必须关闭CSS Modules的哈希功能，或者将BEM的结构性分隔符加入白名单：例如将webpack配置中的 localIdentName: '[name]__[local]--[hash:base64:5]' 改成不含哈希的 [name]__[local]。但这又背离了CSS Modules防止样式冲突的核心初衷。因此，一个更现实的选择是：既然决定采用BEM来管理样式命名，或许可以考虑放弃CSS Modules，转而使用PostCSS插件（如 postcss-bem）进行预处理，或者直接依靠严格的团队命名约定和代码审查流程来保证样式的模块化与隔离。
- 必须认清一点：BEM本质上是一种服务于团队协作的编码规范，而非技术强制手段。它的最大价值在于“肉眼可读”和“团队共识”。
- 哈希化的class名会导致设计稿上标注的
card__header在开发者工具里根本搜不到，极大地增加了设计师与开发者之间的协作成本。 - 如果项目已经重度依赖CSS Modules，或许放弃BEM，转而采用更轻量的命名空间或功能前缀（如工具类
u-text-center、布局类o-layout-grid）是更顺畅的技术路径。
说到底，掌握BEM最难的地方不在于语法规则是否正确。真正的挑战在于，如何让团队中的每一个人——无论是新入职的前端同事、合作的外包伙伴，还是偶尔需要调整模板的后端开发——都能在不查阅冗长文档的前提下，仅凭直觉和命名约定就写出符合规范、不产生冲突、也不越界的class名。这需要的不是某个一劳永逸的自动化工具，而是持续的代码审查、团队沟通和一份清晰明确的命名字典作为共同遵守的准则。
