bem通过命名空间隔离缓解css命名冲突。它将样式归属锁定到具体模块，块名语义唯一（如.product-list），元素名不独立存在（如.__avatar），修饰符仅描述状态（如.--disabled）。
为什么BEM能缓解CSS命名冲突
项目一上规模，.header、.btn这种泛用名很快会失控——组件库、业务模块、第三方样式互相覆盖，改一个按钮边框可能让登录弹窗错位。BEM强制把样式归属锁定到具体模块：.user-card__avatar--large里user-card是块（Block），avatar是元素（Element），large是修饰符（Modifier）。它不靠层级嵌套防冲突，而是靠命名空间隔离。
- 块名必须语义明确且唯一，比如不用
.list而用.product-list - 元素名不能脱离块独立存在，
.__avatar在任何地方都不该单独写样式 - 修饰符只描述状态或外观变化，不表达结构，
--disabled可以，--left-side不行（那是布局逻辑，该交给Flex/Grid）
BEM在React组件中怎么落地
React组件天然对应BEM的“块”，但容易误用：有人把整个ProductCard组件的根
写成
class="product-card"就完事，结果内部所有子元素都用内联样式或CSS-in-JS，BEM形同虚设。- 根元素必须带块名：
className="product-card" - 子元素严格用
<strong></strong>连接：className="product-cardtitle"、className="product-card__price" - 避免深层嵌套选择器，比如不要写
.product-card<strong>content .product-card</strong>title——BEM要求直接写.product-card__title - 修饰符通过动态拼接：
className={<code>product-card__button ${isPrimary ? 'product-card__button--primary' : ''}}
遇到CSS预处理器时BEM写法要注意什么
Sass/Less里用嵌套语法写BEM，看着简洁，实则埋雷。比如这段Sass：
.product-card {
&__title { /* ... */ }
&__button {
&--primary { /* ... */ }
}
}
表面没问题，但一旦需要复用.product-card<strong>button--primary</strong>到其他块（比如.cart-itembutton--primary），就得抽离成mixin或重复写——违背BEM“可复用修饰符”的本意。
- 修饰符类名尽量保持扁平，避免嵌套生成过深的选择器
- 不要用
&<strong>button--primary</strong>这种写法，显式写出全名.product-cardbutton--primary，方便全局搜索和复用 - 如果多个块共用同一组按钮样式，应提取为独立块
.button，而非强行塞进product-card下
团队协作时BEM最常踩的三个坑
命名规范文档写得再细，实际提交代码时照样出问题。最典型的三个现场：
- 块名用缩写：
.usr-card而不是.user-card——缩写无法被搜索工具识别，Git历史里也难追溯 - 元素名带层级暗示：
.user-card<strong>header-title</strong>——header不是元素，是另一个块；这里应该叫.user-cardtitle，样式由user-card内部约束 - 修饰符滥用媒体查询：
.user-card--mobile——响应式应该用容器类或CSS容器查询，而不是给每个块加设备修饰符，否则维护成本指数级上升
BEM不是银弹，它的价值不在语法多漂亮，而在所有人看到.xxx__yyy--zzz时，能立刻判断出这个类属于哪个功能模块、是否可复用、改了会不会影响别处——这点在Code Review时最省时间。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
