BEM是解决多人协作样式冲突的最小可行方案，通过block__element--modifier三段式命名将组件归属、结构和状态直接编码进类名，实现语义化、可预测、可调试的样式隔离。
它不是“必经之路”，而是解决真实协作与维护问题的最小可行方案——当你第一次因为 .btn 被导航栏里另一个 .btn 意外覆盖而花两小时查 !important 来源时，BEM 就不再是“规范”，而是止血钳。
为什么传统 class 命名在多人项目里必然失控
很多人以为冲突是“写得太随意”导致的，其实根源在于 CSS 选择器没有作用域。一个 .title 在 header、card、modal 里反复出现，靠父级上下文（如 .card .title）隔离，等于把逻辑耦合进 HTML 结构——改个 DOM 层级，样式就断；换个人接手，得先读完整个组件树才能动一行 class。
更现实的问题是：你无法从 class 名本身判断它的归属。看到 .active，你得翻三四个文件才能确认它是菜单项状态、按钮状态，还是轮播图指示器状态。BEM 把归属直接编码进名字：.nav__item--active 和 .carousel__dot--active 互不干扰，也不需要猜。
- 所有块级组件必须有唯一、语义化的
block名（如search-form，不用form或search这类泛称） - 元素名只描述功能，不描述样式（用
search-form__input，而不是search-form__text-input） - 修饰符只表达状态或变体（
search-form__button--disabled），不用于描述视觉（避免--blue、--large）
SCSS 中写 BEM 的实际陷阱：嵌套不是万能解药
很多人用 SCSS 的 & 嵌套自动生成 BEM 类名，比如：
立即学习“前端免费学习笔记（深入）”；
.search-form {
&__input { /* ... */ }
&__button { /* ... */ }
&--full { /* ... */ }
}看起来干净，但容易忽略两个事实：
- HTML 必须严格对齐结构：如果某处需要复用
search-form__button却不在.search-form下，你就得额外写一条顶层规则，破坏 BEM 的一致性 -
@at-root不解决语义断裂——嵌套生成的.search-form__button--loading如果在 JS 里通过el.classList.add('loading')动态加类，就和 BEM 体系脱节了 - 过度嵌套会让调试困难：Chrome DevTools 里看到的 class 是拼出来的，但你没法反向定位到 SCSS 文件哪一行定义了它，除非命名足够直白
BEM 不是命名游戏，而是接口契约
真正让 BEM 发挥价值的，是把它当成组件对外暴露的“样式 API”。比如一个 Vue 组件 Card.vue，它的公开 class 接口就是：
-
card（block）—— 必须存在，且只用于该组件根节点 -
card__header/card__body/card__footer（elements）—— 子内容区域的约定位置 -
card--shadowless/card--compact（modifiers）—— 可选状态，JS 控制开关
这样，其他开发者不用看实现，只看 class 名就能安全地使用、扩展、测试这个组件。一旦有人擅自加了个 card__icon--small，你就知道这违反了契约——icon 不是 card 的标准元素，应该抽成独立 block 或走 slots。
最常被忽略的一点：BEM 的边界感极强。它不鼓励“跨块组合”，比如不会出现 nav__card__title。如果真有这种需求，说明设计上该拆出新 block，而不是在命名上打补丁。
