深层嵌套CSS选择器显著拖慢样式计算，因浏览器从右向左匹配，需对每个最右元素逐层回溯父级；≥4层易致layout thrashing，BEM等扁平单类名可有效优化。
深层嵌套的 CSS 选择器会显著拖慢浏览器样式计算（Recalculate Style），不是因为名字长，而是因为匹配过程要从右往左反复回溯父级——.page .main .card .card__title 这种写法在低端 Android 设备上可能比 .card__title 慢 4 倍以上。
为什么浏览器匹配 .a .b .c 比 .c 慢得多
浏览器解析选择器时，永远从最右边开始：先找所有 .c 元素，再逐个向上检查它的父级是否是 .b，再查 .b 的父级是否是 .a。DOM 越大、嵌套越深，回溯路径越长，尤其在 hover 或动画触发批量重算时，style recalculation 时间会突然飙升。
- ≥4 层嵌套在移动端极易引发 layout thrashing，Chrome DevTools Performance 面板里能看到“Recalculate Style”任务持续 >16ms
-
:hover、:nth-child()等伪类放在最右端（如ul li:hover）会让匹配更重，iOS Safari 尤其敏感 - 即使你用 Sass 写了
&__title { &:hover {} }，只要最终编译出带空格的选择器，就逃不掉回溯成本
如何用 BEM 真正生成扁平选择器，而不是“假装扁平”
BEM 本身不提升性能，它只是一种命名约定；真正起作用的是你最终输出的 CSS 是否全是单类名。很多团队写了 .card__title 却还在 HTML 里加一层 .card .card__title，等于白做。
- ✅ 正确：HTML 直接写
<h2 class="card__title"></h2>，CSS 只写.card__title { ... } - ❌ 错误：HTML 写
<div class="card"> <h2 class="card__title">，CSS 却写 <code>.card .card__title { ... }—— 这仍是两层嵌套 - ⚠️ 注意：
@use在 Sass 中不会自动扁平化，.card { &__title { color: red; } }编译后是.card__title，但若混用.card &__title，就会产出.card .card__title - 工具验证：构建后搜 CSS 文件里的空格 + 点号组合，
grep -r "\.[a-z]\+ \.[a-z]" dist/能快速揪出残留嵌套 - 媒体查询内允许 1 层嵌套：
@media (min-width: 768px) { .nav__item { display: flex; } }—— 安全，不增加运行时回溯 - 状态修饰符前置：
.is-open .modal__content比.modal.is-open .modal__content更易维护，且仍只有 2 层 - CSS-in-JS 场景下，用
:where(.card) .card__title降权并避免嵌套，:where()不影响优先级，也不增加匹配开销 - 第三方组件封装：不要覆盖
.el-button，而用.my-form__submit-btn包一层，再用:deep(.el-button)（Vue）局部穿透
哪些地方必须保留有限嵌套，又不破坏性能
完全零嵌套不现实，关键控制深度 ≤ 2 层，并锁死作用域。BEM 不反对嵌套，反对无意义的祖先链依赖。
最容易被忽略的一点：BEM 的性能收益不是来自“命名好看”，而是让构建工具能安全地 tree-shake 未使用的类。一旦选择器变成 .card__title 这种原子单位，PurgeCSS 或 lightningcss 才能精准剔除 .card__footer（如果组件没用到）。而 .card .footer 这种写法，工具根本不敢删——怕删错了某个没被扫描到的 DOM 结构。
