单类名选择器（如 .card__title）比后代选择器（如 .card .card__title）快，因浏览器从右匹配时无需向上回溯父级；BEM 通过强制单类名提升性能，但错误嵌套或编译会 reintroduce 空格导致回溯。
直接用单类名选择器（如 .button__icon--large）能显著加快浏览器样式匹配速度；BEM 本身不提速，但强制你产出这种选择器，从而避开从右往左匹配时的多层 DOM 回溯。
为什么 .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类规则触发频繁重排
哪些 BEM 写法实际破坏了性能优势
名字带双下划线 ≠ 真 BEM。很多团队用 Sass 写了 .card { &__title { color: red; } }，以为安全，结果一加 &:hover 或误用 @at-root，就编译出 .card .card__title:hover ——空格回来了，回溯也回来了。
立即学习“前端免费学习笔记（深入）”；
必须避免的写法：
-
.card { &__content { &:hover { } } }→ 编译为.card .card__content:hover -
.card { @at-root .header &__title { } }→ 生成全局作用域 + 嵌套组合器 -
.modal__content在 HTML 里被包裹在<div class="modal"><div class="modal__content">中，但 CSS 仍写.modal .modal__content
伪类位置也很关键：.card__title:hover 语义错（标题自己不 hover），且若它真被用于交互，应由 JS 切换 .card--hovered .card__title ——但这又引入空格；更优解是 .card__title.is-hovered 或纯 CSS .card__title:hover（仅当它可独立响应）。
怎么验证你的 CSS 真正在跑高性能路径
别信文件名、别信 Sass 结构、别信注释——只看最终注入页面的选择器字符串。
实操建议：
- 打开 DevTools → Elements → 选中目标元素 → 右侧 Styles 面板点开某条规则，确认选择器是
.form__input，不是.form .input - 命令行快速扫雷：
grep -r "\.[a-z]\+ \.[a-z]" src/css/（Linux/macOS），命中即违规 - Webpack 用户可在
css-loader配置中启用exportOnlyLocals: true，防止嵌套规则意外泄漏到全局 - 禁用
:is()或:where()包裹 BEM 类——它们虽简化书写，但旧版 Safari 不支持，且掩盖真实选择器复杂度
BEM 和 CSS-in-JS / scoped CSS 共存时的坑
Vue 的 <style scoped> 默认给元素加 data-v-xxx 属性，并重写选择器为 .btn[data-v-abc123] ——这会让原本高效的 .btn 变成属性选择器，轻微拖慢解析。
规避方式：
- Vue CLI 项目中，在
vue.config.js关闭 scoped 属性注入（需配合 PostCSS 插件或自定义 loader） - React + Emotion 场景下，避免动态插值生成 css：
${props => props.theme.primary}每次渲染都可能产生新规则，比 BEM 嵌套更难追踪 - 和 Tailwind 共存时，只用 BEM 定义结构（
card card--featured），视觉样式交给 utility class（p-6 bg-white），不混用@apply封装 modifier
真正容易被忽略的是：BEM 类名变长本身不增加匹配成本，但若因命名模糊导致后续所有人复制粘贴都带上冗余祖先链（比如三个月后出现 17 处 .modal .modal__content p a），问题就从选择器性能，升级为协作失控。
