.card__title比.card .card__title快得多，因浏览器从右匹配时前者直接哈希查找一次命中，后者需对每个card__title元素向上回溯父节点验证card类，dom越深耗时越高，低端设备实测慢4倍以上。
因为BEM本身不提升性能，真正起效的是它强制你写出的单类名选择器（如.card__title），让浏览器跳过从右往左的DOM回溯匹配——但前提是严格落地，否则写再多__和--也白搭。
为什么.card__title比.card .card__title快得多
浏览器匹配CSS永远从最右边开始：遇到.card .card__title，先找所有带card__title类的元素，再逐个往上查父节点是否含card类；而.card__title直接查class哈希表，一次命中。DOM越深、元素越多，前者耗时可能高出4倍以上，尤其在滚动、hover或动画触发批量重算时。
- 实测中，“Recalculate Style”在低端Android设备上超过16ms，大概率就是这类嵌套选择器拖慢的
- Sass里写
.card { &__title { } }是安全的，但混用.card &__title会编译出带空格的选择器 - 构建后用
grep -r "\.[a-z]\+ \.[a-z]" dist/能快速揪出残留的空格分隔选择器
哪些BEM写法看似规范，实际破坏性能
名字带双下划线≠真BEM。很多团队用预处理器“假装”在写BEM，结果输出的仍是慢选择器。
-
.card { &__content { &:hover { } } }→ 编译成.card .card__content:hover，空格+伪类双重开销 -
@media (min-width: 768px) { .card .card__title { } }→ 应该用.card__title--lg，而非退化为嵌套 -
.card__title:hover语义错误且不可控；正确做法是JS切换.card--hovered，再配.card--hovered .card__title（深度≤2且可控） - 误用
:is(.card) .card__title看似扁平，实则仍是两层匹配，且iOS Safari 15.4以下不支持
HTML结构不配合，BEM就失效
BEM性能优势只在DOM层级与CSS选择器对齐时成立。光CSS写对了，HTML没跟上，照样白干。
- ❌ 错误：
<div class="card"> <h2 class="card__title"> + <code>.card .card__title { } - ✅ 正确：
<h2 class="card__title"></h2>+.card__title { }（根节点直接挂Element类） - 每个元素只允许一个BEM类：禁止
class="card card--featured"，应直接用card--featured - VirtualList中每个item必须是
<li class="user-list__item">，禁叠list-item等非BEM类
真正卡住性能的，从来不是类名长度，而是选择器是否真实扁平、是否被构建流程悄悄转义、是否在媒体查询或伪类场景下退化——这些地方不盯紧，BEM就只是个好听的名字。
