bem能天然限制选择器深度，因其强制使用单类名（如.card__title）实现浏览器哈希查找、一次命中、零回溯；而空格、>、标签或属性选择器等写法会触发从右往左的dom回溯，≥4层嵌套在低端设备上recalculate style耗时可高4倍以上。
为什么BEM能天然限制选择器深度
浏览器匹配CSS选择器是从右往左执行的，.card .card__title这种写法会让引擎先找所有card__title元素，再逐个向上检查父级是否含card类——DOM越深、同名元素越多，回溯成本越高。而BEM强制用.card__title单类名，浏览器直接哈希查找，一次命中，不回溯。
这不是“命名习惯优化”，而是匹配机制决定的硬性事实：≥4层嵌套在低端Android设备上，Recalculate Style耗时可能比单类名高4倍以上。
哪些CSS写法会悄悄破坏BEM的扁平性
很多项目写了card__title类名，却仍在CSS里写带空格的选择器，等于白用BEM。
-
.card .card__title：典型反模式，空格即后代选择器，触发回溯 -
.card > .card__title：仍依赖层级，违背BEM“结构无关”原则 -
button.card__submit：混用标签选择器，权重低且污染全局 -
.card__title:hover：语义错（标题本身不可hover），应改用.card--hovered .card__title并由JS切换
验证方法：打开Chrome DevTools → Elements → 选中元素 → Computed → Styles，确认每条规则都是纯.xxx，不含空格、标签或属性选择器。
怎么用工具守住BEM边界不退化
靠人眼检查容易漏，必须加自动化约束。
- 构建后执行
grep -r "\.[a-z]\+ \.[a-z]" dist/，快速揪出所有带空格的选择器残留 - Sass中禁用
& .title这类嵌套，只允许&__title和&--active - 接入
stylelint-selector-bem-pattern，对.card-header-title（缺__）或.card_title（单下划线）实时报错 - Webpack用户配置
css-loader的exportOnlyLocals: true，避免意外注入全局嵌套规则
修饰符和媒体查询怎么嵌套才不算破功
BEM不禁止所有嵌套，但只允许三类安全场景，且深度≤2：
- 媒体查询内保持扁平：
@media (min-width: 768px) { .header__logo--large { } }，而非@media () { .header .logo { } } - 状态修饰符前置：
.is-open .modal__content是可接受的2层，比.modal.is-open .modal__content更易维护 - 伪类必须放在最右边：
.card__submit:hover会触发全量扫描，应改用.card__submit--hovered配合JS切换
真正卡住性能的，从来不是类名长度，而是选择器结构失控后引发的隐性回溯成本。哪怕只有一处.list .item a残留，在长列表滚动中都可能成为帧率瓶颈的起点。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
