4层CSS选择器会卡顿，因浏览器从右往左匹配，需对每个.title元素逐层向上验证父级，DOM超500节点时Recalculate Style易超20ms导致掉帧；BEM通过单类名（如.card__title）彻底消除回溯，是硬性性能门槛而非建议。
为什么4层选择器就会卡顿
浏览器匹配CSS是从右往左查的，不是顺着DOM树往下找。.page .main .content .card .title的意思是：先找出所有.title元素，再对每个逐个向上验证父级是不是.card、再是不是.content……每多一层，回溯链就多一次遍历。DOM节点一过500个，Recalculate Style阶段很容易超20ms，滚动直接掉帧。这不是理论值，是低端Android WebView实测数据——4层就是临界点，不是建议，是硬门槛。
BEM不是起名规则，是切断匹配路径
BEM的核心作用，是让样式只依赖一个类名，彻底绕过向上回溯。它不是语法糖，是语义映射协议：card__title必须显式出现在HTML里，缺card就完全不生效。
-
<h2 class="card__title"></h2>✅ 匹配单类，零回溯 -
<h2 class="title"></h2>❌ 即使CSS写.card .title，仍触发三层回溯 - 禁止
card__header__logo这种跨层Element，应拆成card__header和card__logo两个独立类 - 修饰符必须能独立存在：
button--loading不能依赖button类才生效，否则element.classList.add("button--loading")会失效
@at-root不是逃逸键，是提级开关
@at-root解决的是“逻辑上该平级，却被嵌套裹挟”的问题。它不救烂结构，只防冗余拼接。
- 错误写法：
.modal { .overlay { @at-root .tooltip { top: -10px; } } }→ 编译出.tooltip，正确 - 错误写法：
.btn { @at-root { &--large { font-size: 18px; } } }→ 编译失败，@at-root后面必须跟完整选择器 - 媒体查询内禁用
&嵌套：@media (min-width: 768px) { .card { &__body { } } }若外层有.layout .dashboard，会产出6层选择器 - 工具类必须提级：
@at-root .u-text-center { text-align: center; }→ 输出.u-text-center，不带任何父前缀
怎么快速发现和拦截深层嵌套
别等上线后看卡顿，构建阶段就得卡住。
立即学习“前端免费学习笔记（深入）”；
- 命令行扫描：
npx lessc input.less | grep -E "\.[a-z]+(\s+\.[a-z]+){3,}"找出所有4+类名选择器 - VS Code装Less IntelliSense，第4层缩进自动标黄——这不是提示“还能忍”，是重构成本最低的信号
- Webpack/Vite中接入
postcss-selector-max-specificity，设阈值为0,2,0，超限直接构建失败 - CI加粗筛：
grep -r "\.[a-z]\+.*{" src/styles/ | grep -E "{.{12,}"（12+空格≈4层缩进）
真正容易被忽略的是：性能瓶颈往往不出现在“写了什么”，而出现在“改了什么”——比如给某个.card加个新状态类，结果触发整条4层选择器重匹配，而你根本没动那行CSS。
