单类名选择器（如.card__title）比嵌套选择器快，因浏览器从右匹配时可哈希查找、零回溯；而.card .card__title需对每个.card__title向上验证父级，dom越深回溯越重，低端机上5层嵌套比单类名慢4倍以上。
直接用单类名选择器（如 .card__title）就能显著降低 CSS 匹配开销，BEM 本身不提速，但强制你写出浏览器能一次哈希查找的选择器——这是移动端 WebView 渲染性能最常被忽视的瓶颈。
为什么 .card__title 比 .card .card__title 快得多
浏览器解析 CSS 时永远从最右边开始匹配：.card__title 直接查哈希表，.card .card__title 则先找所有 .card__title 元素，再逐个向上检查父节点是否含 .card 类。DOM 越深、节点越多，回溯越重。
- 低端 Android 设备上，5 层嵌套选择器实测比单类名慢 4 倍以上
- DevTools Performance 面板里 “Recalculate Style” 单次耗时 >16ms，滚动/悬停卡顿，大概率是这类回溯导致
- 现象：列表项大量复用时，
.item .content p这类规则频繁触发重排，但改写成.item__content后明显缓解
哪些 BEM 写法实际破坏了性能优势
名字带双下划线 ≠ 真 BEM。很多团队用 Sass 写了 .card { &__title { } }，以为安全，结果一加 &:hover 或误用 @at-root，就编译出带空格的选择器——回溯立刻回来。
-
.card { &__content { &:hover { } } }→ 编译为.card .card__content:hover -
.card { @at-root .header &__title { } }→ 生成全局作用域 + 嵌套组合器 -
.modal__content在 HTML 里被包裹在<div class="modal"><div class="modal__content"> 中，但 CSS 仍写 <code>.modal .modal__content—— 这是典型自毁式写法 - 伪类位置错误：
.card__title:hover语义错（标题自己不 hover），且若真用于交互，应由 JS 切换.card--hovered .card__title，但这又引入空格；更优解是.card__title.is-hovered或纯 CSS.card__title:hover（仅当它可独立响应） - 打开 DevTools → Elements → 选中目标元素 → 右侧 Styles 面板点开某条规则，确认选择器是
.form__input，不是.form .input - 命令行快速扫雷：
grep -r "\.[a-z]\+ \.[a-z]" src/css/（Linux/macOS），命中即违规 - Webpack 用户可在
css-loader配置中启用exportOnlyLocals: true，避免意外注入全局嵌套规则 - CI 中建议接入
stylelint-selector-bem-pattern，拦截.modal .modal__close这类写法
如何验证你的 CSS 真正在跑高性能路径
别信文件名、别信 Sass 结构、别信注释——只看最终注入页面的选择器字符串。
真正拖慢渲染的从来不是类名长度，而是空格和嵌套带来的 DOM 回溯。构建后打开控制台看一眼 Elements 面板里的真实选择器，比读十遍 BEM 文档都管用——很多项目所谓“用了 BEM”，其实只是在 Sass 里写了 &__，最终输出的仍是带空格的后代选择器。
