单类名选择器（如 .card__title）比后代选择器（如 .card .card__title）快，因浏览器从右匹配时直接哈希查找，无需向上回溯父级；而后者需先找所有.card__title再逐个验父级.card，dom越深回溯越重，低端android设备上5层嵌套可慢4倍以上。
直接用单类名选择器（如 .tab-bar__item）能显著提升移动端 CSS 解析速度，因为浏览器从右匹配时无需向上回溯父级；但若 HTML 结构没对齐、预处理器编译出带空格的选择器，或媒体查询里退化为嵌套写法，BEM 就完全失效。
为什么 .card__title 比 .card .card__title 快得多
浏览器解析 CSS 时永远从最右边开始匹配：.card__title 直接查 class 哈希表，一次命中；而 .card .card__title 先找所有 .card__title 元素，再逐个向上检查父节点是否含 .card 类——DOM 越深、节点越多，回溯开销越大。在低端 Android 设备上，5 层嵌套选择器实测比单类名慢 4 倍以上，滚动或悬停时“Recalculate Style”单次耗时常超 16ms。
哪些 BEM 写法看似规范，实际破坏性能
名字带双下划线 ≠ 真 BEM。很多团队用 Sass 写了 .card { &__title { } }，以为安全，结果一加 &:hover 或误用 @at-root，就编译出 .card .card__title:hover——空格回来了，回溯也回来了。
-
.card { &__content { &:hover { } } }→ 编译为.card .card__content:hover，双重开销 -
.modal { @at-root .header &__title { } }→ 生成全局作用域 + 后代组合器 -
@media (min-width: 768px) { .card .card__title { } }→ 应该用.card__title--lg，而非退化为嵌套 -
.card__title:hover语义错（标题自己不 hover），且真要交互，应由 JS 切换.card--hovered .card__title，但深度必须 ≤2 且可控
如何验证现有 CSS 是否真符合 BEM 性能逻辑
光看文件名或注释没用，得看最终生成的选择器字符串。构建后打开 DevTools → Elements → 选中元素 → 查看 Computed 面板右侧的 “Styles” 标签页，确认选择器是单类名（如 .form__input）而非带空格的组合（如 .form .input）。
- Linux/macOS 下可用：
grep -r "\.[a-z]\+ \.[a-z]" dist/快速扫出含空格的选择器 - Webpack 用户可在
css-loader配置中启用exportOnlyLocals: true，避免意外注入全局嵌套规则 - CI 中建议接入
stylelint-selector-bem-pattern，拦截.modal .modal__close这类写法
真正卡住性能的，从来不是类名长度，而是选择器是否真实扁平、是否被构建流程悄悄转义、是否在媒体查询或伪类场景下退化——这些地方不盯紧，BEM 就只是个好听的名字。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
