到了2026年，BEM 命名规范依然没有被真正取代，原因其实很明确：它仅凭一套清晰、稳定的命名规则，就能有效隔离 CSS 样式作用域，完全不必依赖额外的构建工具。反过来看，虽然 CSS Modules 可以通过哈希机制自动处理类名，但一旦导出的类名需要提供给外部使用，命名冲突往往仍然需要人工规避；相比之下，像 BEM 中的 button__icon--loading 这类命名，天然就包含组件归属与状态语义，表达更直观也更完整。
适用，而且在大多数中大型前端项目中，它仍然是首选方案——并不是因为它足够“先进”，而是因为 BEM 解决的是样式冲突、作用域不清、团队协作成本高等这些不会随着技术演进而消失的底层问题。
为什么 BEM 在 2026 年依然没有被替代
BEM 不需要绑定任何构建工具，也无需依赖运行时框架，只靠一套明确的 CSS 命名规范，就能把样式作用域划分得非常清楚。CSS Modules 确实能够自动为类名生成哈希值，但只要类名需要导出给外部组件使用，比如 className={styles.button}，后续依旧离不开人为约束来减少冲突。相比之下，BEM 像 button__icon--loading 这样的写法，即使完全没有构建流程，也能让开发者快速看出它属于哪个模块，以及当前处于什么状态。
- 在微前端场景中，多个团队同时开发时，像
header这样的通用类名几乎不敢直接使用，只有app-header__logo--dark这类写法才能清晰标识归属 - 在 Vue 或 React 组件拆分之后，
user-card__a vatar比a vatar更容易通过 grep 搜索定位，同时也能减少 scoped 样式穿透时出现的意外覆盖问题 - 浏览器匹配
.user-card__a vatar--sm属于单次哈希查找；而.user-card .a vatar则需要额外回溯父级节点，DOM 层级一深，性能就更容易下降
哪些情况容易踩坑：伪 BEM 和跨块元素
最常见的问题并不是 BEM 过时，而是很多项目在使用过程中把写法逐渐弱化了。比如：
...
.title一旦进入全局作用域，就很容易发生样式冲突出现在非search-form容器中 —— element 脱离所属 block，语义链条被打断，复用时也更容易造成样式错乱- Sass 中写
.card { &__title { color: red; } & .card-subtitle { ... } }—— 后者最终会编译出带空格的选择器，从而破坏 BEM 原本的命名约束
这类写法表面上看像是在使用 BEM，实际上已经失去了样式作用域的保护能力，真正排查 bug 时往往会更难处理。
Modifier 必须与基础类同时存在，不能单独使用
button--disabled 如果单独使用，会直接丢失所有基础样式，例如 padding、border、font-size 等，因此必须写成 button button--disabled。
- modifier 不是独立的样式单元，它本质上只是对某个 block 或 element 状态的补充描述
- 如果写成
button--width-200px这类带具体数值的 modifier，后续一旦需要响应式调整宽度，就只能继续新增类名，这违背了“状态可枚举”的原则 - 合法的 modifier 示例：
button--primary、button--disabled、button--loading；不推荐的写法：button--bg-blue、button--left
真正困难的地方，不是记住 __ 和 -- 该怎么写，而是每次命名类名时都能克制住“先图省事再说”的冲动——不使用标签选择器、不把具体样式值塞进类名、不跨 block 复用 element 名称。这些约束看起来不起眼，但只要缺少其中任何一条，BEM 就会从一种可靠的工程化规范，退化为一种表面化的命名习惯。
