BEM 能直接解决样式冲突，因其将选择器从“靠结构猜意图”变为“靠名字定归属”，通过块前缀（如 .article__title）锁定作用域、天然隔离、不依赖 DOM 层级、修饰符强制共存来避免冲突。
它不丑，是你的编辑器还没配好高亮、你的团队还没形成语义反射——BEM 类名长，但每一截都在回答「这是谁的、属于哪部分、现在是什么状态」这三个问题。工程上它不是为了“好看”，而是为了降低 git blame 时的心跳速度。
为什么 BEM 能直接解决样式冲突
BEM 把 CSS 选择器从「靠结构猜意图」变成「靠名字定归属」。传统写法里 .title 可能出现在任何地方，没人知道它是文章标题、弹窗标题还是侧边栏标题；而 .article__title、.modal__title、.sidebar__title 一出现，作用域就锁死了。
- 所有类名都带块前缀，天然隔离：改
.card__title不会影响.list__title - 不依赖 DOM 层级，删掉一个父元素不会让样式失效（不像
.card .title） - 修饰符必须和基础块共存，比如
.button--disabled永远要配合.button使用，避免孤立状态类被误复用
什么时候不该用 BEM：三个典型误用场景
BEM 不是银弹，硬套反而增加认知负担：
- 原子类场景：像
.mt-2、.text-center这类工具类，BEM 强制加块前缀（如.layout__mt-2）会破坏其通用性 - 纯布局容器：比如只起网格/间距作用的
.container、.row，本身无业务语义，套 BEM（.page__container）反而模糊职责 - JS 临时状态类：如
.is-open、.has-error，这类由 JS 控制、不参与样式的“开关类”，BEM 不适合——它不表达结构，只表达瞬时状态
CSS Modules + BEM 是目前最稳的轻量组合
不用 CSS-in-JS，又想享受模块化收益？Button.module.css 里写 .button {}、.button__icon {}、.button--loading {}，再通过 import styles from './Button.module.css' 在组件中引用 styles.button ——这样既避免全局污染，又保留了 BEM 的可搜索性与 IDE 重命名支持。
- 搜索
button--loading能立刻定位到所有使用位置，包括 JS 中的className={styles.button + ' ' + styles['button--loading']} - VS Code 重命名
button块时，自动更新所有button__*和button--*类名（需开启"javascript.preferences.renameImportsOnFileMove": true） - 打包后类名可哈希（如
Button_button__abc123），开发期仍保持可读，上线后又防冲突
真正容易被忽略的不是命名规则本身，而是团队对「块」的定义共识：一个 .header 是块，但它里面的 .logo 是另一个独立块，还是它的 .header__logo 元素？这个边界一旦模糊，BEM 就会退化成“加长版普通类名”。定好第一个块，后面才不会越写越乱。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
