BEM在2026年仍未被替代，因其仅靠命名约定即可实现样式作用域隔离，不依赖构建工具；而CSS Modules虽能自动哈希类名，但导出类名供外部使用时仍需人工避免冲突，BEM的button__icon--loading等写法则天然具备归属与状态语义。
适用，而且在多数中大型项目里仍是首选——不是因为它“先进”，而是它解决的是样式冲突、作用域模糊、协作成本这些不会随时间消失的底层问题。
为什么 BEM 在 2026 年还没被替代
BEM 不依赖构建工具或运行时框架，只靠命名约定就能隔离样式作用域。CSS Modules 虽然自动哈希类名，但一旦你导出类名给外部组件用（比如 className={styles.button}），就又得靠人来保证命名不撞车；而 BEM 的 button__icon--loading 这种写法，哪怕没构建步骤，也能一眼看出归属和状态。
- 微前端场景下，多个团队并行开发，
header这种泛名根本不敢用，app-header__logo--dark才能明确归属 - Vue/React 组件拆分后，
user-card__avatar比avatar更容易 grep 定位，也避免了 scoped 样式穿透时的意外覆盖 - 浏览器匹配
.user-card__avatar--sm是单次哈希查找；而.user-card .avatar需要回溯父级，DOM 深了性能就掉
哪些情况会踩坑：伪 BEM 和跨块元素
最常见的失效不是 BEM 本身过时，而是写法退化。比如：
-
<div class="card"><h3 class="title">...—— 漏掉 block 前缀，.title一进全局就打架 -
<div class="search-form__input">出现在非search-form容器里 —— 元素脱离所属 block，语义断裂，复用时样式错乱 - Sass 中写
.card { &__title { color: red; } & .card-subtitle { ... } }—— 后者编译出空格选择器，破坏 BEM 约束
这类写法看着像 BEM，实际失去作用域保障，查 bug 时反而更难定位。
PigX UI 前端开发
下载
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
立即学习“前端免费学习笔记（深入）”；
Modifier 必须和基础类共存，不能单独使用
button--disabled 单独用会丢失所有基础样式（padding、border、font-size 等），必须写成 button button--disabled。
- 修饰符不是独立样式单元，它只是对某个 block 或 element 的状态描述
- 写成
button--width-200px这类带具体值的 modifier，响应式改宽度就得新增类，违背“状态可枚举”原则 - 合法 modifier：
button--primary、button--disabled、button--loading；非法：button--bg-blue、button--left
真正难的不是记住 __ 和 -- 怎么用，而是每次写类名时都克制住“图快”冲动——不用标签选择器、不塞样式值、不跨块复用元素名。这些约束不显眼，但缺一条，BEM 就从工程保障退化成一种装饰性习惯。
