BEM能减少CSS选择器冲突，因其强制将组件关系写入类名（如header__nav、header--dark），使样式作用域显性化、脱离DOM结构层级，避免嵌套选择器导致的覆盖与漏匹配问题。
为什么BEM能减少CSS选择器冲突
BEM（Block-Element-Modifier）不是为了“看起来高级”，而是让样式作用域显性化。传统写法里 .header .nav a:hover 这种嵌套，一旦组件复用或结构微调，就容易漏掉某层、多套一层，或者被其他同名类意外覆盖。
BEM强制把关系写进类名：header__nav 表示它是 header 的子元素，header--dark 表示变体，和结构层级脱钩。浏览器不关心你是不是嵌套了三层 div，它只认类名是否匹配——所以只要类名唯一、语义清晰，选择器就不会“越界”。
- 类名自带作用域，不需要靠父级容器限制范围
- 不依赖 DOM 结构深度，组件挪位置、抽离成独立模块都不用改样式
- 搜索
button--primary就能定位全部相关样式，不用 grep 整个 CSS 文件找上下文
BEM命名时最容易写错的三种情况
新手常把 BEM 当成“加两个下划线就行”，结果写出一堆难以维护的类名：
- 把业务逻辑塞进 Element 名：写成
user-card<strong>delete-btn</strong>——delete-btn是行为，不是结构角色；应改为user-cardaction或user-card<strong>control</strong>，再用 Modifier 区分类型，比如user-cardcontrol--delete - Modifier 名用了形容词但没对应状态：比如
input--big，但“big”是相对谁？没有统一基准，不同开发者会各自解释；应改用语义明确的状态名，如input--expanded（表示已展开）、input--disabled（标准可交互状态） - Block 命名过度具体：写成
homepage-hero-banner，导致无法复用到其他页；应抽象为hero-banner，靠组合使用（如hero-banner--homepage）来表达上下文
如何在现有项目中渐进式接入BEM
全量重命名不现实，重点是“新代码遵守，旧代码有迁移路径”：
立即学习“前端免费学习笔记（深入）”；
- 新增组件/样式必须用 BEM，老样式不主动动，但修改时顺手转成 BEM（比如修一个 bug 顺带把
.sidebar ul li a改成sidebar__item-link） - 工具辅助识别风险：用 PostCSS 插件
postcss-bem-linter扫描不符合 BEM 规范的类名，CI 中报错提醒 - CSS 预处理器里用嵌套模拟 BEM 关系，但只用于生成，不用于书写逻辑：Sass 中写
.button { &__text { } &--large { } }可以，但不要靠嵌套层级控制样式生效条件 - 公共工具类（如
u-text-center）保留 utility class 命名风格，和 BEM 并存，不强行套用 —— 它们解决的是另一维度的问题
用 BEM 后，CSS 文件体积和性能真的变差了吗
不会。BEM 类名略长，但 gzip 后差异几乎为零；真正影响性能的是选择器复杂度和重绘触发频率。
- BEM 类名全是单类选择器（
.block__element），比.container .sidebar ul li a这种多层后代选择器更轻量，浏览器匹配更快 - 没有过度依赖
!important或内联样式来“覆盖优先级”，减少了样式计算负担 - 如果发现打包后 CSS 明显膨胀，问题大概率出在：重复生成 Modifier（比如为每个颜色写一个
btn--red/btn--blue），而不是 BEM 本身——这时该用 CSS 自定义属性统一控制，类名只负责开关，不负责值
BEM 的维护成本不在写法，而在团队对“Block 边界”和“Element 职责”的共识。一个按钮要不要单独抽成 Block，还是永远作为 form__control 存在——这种判断没法靠规则自动解决，得靠 Code Review 和文档沉淀。
