浏览器匹配css选择器永远从右往左解析，因此单类名如.card__title--hovered可直接哈希查找一次命中，而.card .card__title需先找所有card__title元素再向上回溯父节点，在低端设备上性能差距可达4倍以上。
浏览器匹配 CSS 选择器时，永远从右往左解析；.card__title--hovered 这种单类名能一次哈希查找命中，而 .card .card__title 会触发 DOM 回溯，性能差距在低端设备上可达 4 倍以上。
为什么“从右往左”让单类名更快
浏览器不关心你写的顺序，它只看最右边那个“关键选择器”（rightmost selector）。遇到 .card .card__title，它先扫描所有带 card__title 类的元素，再逐个往上查父节点是否含 card 类——DOM 越深、列表越长，这个回溯链就越耗时。而 .card__title 是纯类名，浏览器直接查 class 属性的哈希表，无回溯、无遍历。
哪些写法看似 BEM 实际破功
常见错误不是类名没双下划线，而是最终 CSS 里混进了空格或标签：
-
.card { &__title { } }在 Sass 中若未禁用嵌套，会编译出.card .card__title -
div.card__title多了标签前缀，强制浏览器多做一次标签判断 -
[data-state="loading"] .btn属性选择器 + 空格，双重开销 -
.card__title:hover把伪类放在最右，仍会全量扫描所有:hover元素
怎么验证你的 CSS 真正在走单类路径
别信源码结构，只看最终注入页面的选择器字符串：
- 打开 Chrome DevTools → Elements → 选中目标元素 → 右侧 Styles 面板，逐条检查每条规则的选择器是不是纯
.block__element--modifier形式 - 命令行快速扫雷：
grep -r "\.[a-z]\+ \.[a-z]" dist/，命中即存在空格分隔的后代选择器 - Webpack 用户可配置
css-loader的exportOnlyLocals: true，防止嵌套规则意外泄漏到全局
真正卡住性能的，从来不是类名长度，而是选择器结构失控后引发的隐性回溯成本；哪怕只有一处 .list .item 残留，在长列表滚动或 hover 动画中，都可能成为帧率瓶颈的起点。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
