嵌套超过3层会导致浏览器匹配变慢、权重失控、调试困难，是真实可测的性能退化；应避免深层嵌套，优先使用BEM类名扁平化结构，并正确使用&和@at-root控制编译结果。
嵌套超过3层会让浏览器匹配变慢、权重失控、调试困难——这不是风格偏好，是真实可测的性能退化。
浏览器从右往左匹配，每多一层就多一次回溯
Less不改写匹配逻辑，它只把缩进原样转成空格分隔的选择器。比如.page .layout .main .content p，浏览器必须：先找所有p，再逐个检查父元素是不是.content，再查该.content是否在.main里……DOM节点越多，这个过程越耗时。
低端设备或安卓 WebView 中，这种4层选择器的Recalculate Style时间可能比.content-p慢4倍以上。
- 用
npx lessc input.less | grep -E "\.[a-z]+(\s+\.[a-z]+){3,}"可扫出所有4+类名的选择器 - Chrome DevTools 的 Performance 面板里，“Recalculate Style”突然飙升，大概率就是这类选择器在拖后腿
- 伪类如
:hover放在最右边（如.card .title:hover）会触发全量扫描，比.title--hovered多出2–3倍成本
& 符号用错等于主动加权，不是省事而是埋雷
&是父选择器的完整副本，不是作用域占位符。它决定编译结果是拼接类名（低权），还是后代关系（高权）。
立即学习“前端免费学习笔记（深入）”；
- ✅ 安全：
.btn { &__icon { display: inline-block; } }→ 编译为.btn__icon（权重 0-1-0） - ✅ 安全：
a { &:hover { color: blue; } }→a:hover（0-1-1），伪类不增加层级计数 - ❌ 危险：
.modal { & .close { opacity: 0.5; } }→.modal .close，多一层无意义后代关系，权重+1 - ❌ 危险：
.list { & li { margin: 4px; } }→ 实际仍是.list li，&完全没起作用
@at-root 不是用来“救”深层嵌套的
@at-root的作用是切断当前嵌套链对后续规则的前缀继承，不是给4层缩进打补丁。
- ✅ 正确：
.btn { @at-root @media (min-width: 768px) { &--large { font-size: 18px; } } }→ 输出@media (min-width: 768px) { .btn--large { } } - ✅ 正确：
.modal { .overlay { @at-root .tooltip { top: -10px; } } }→ 输出.tooltip { top: -10px; }，完全脱离父级上下文 - ❌ 错误期待：
.card { .body { .title { .highlight { } } } }想靠@at-root缓解——第一反应应是删掉两层缩进，改用.card { &__title { } }
BEM不是命名规范，是结构映射工具
把 DOM 深度转成类名语义，而不是靠缩进模拟父子关系。真正容易被忽略的是：嵌套和BEM不是二选一，而是分工关系。
- 错：
.card { .body { .title { color: red; } } }→ 编译出.card .body .title（0-3-0） - 对：
.card__title { color: red; }→ 权重恒为 0-1-0，可被.card__title--large干净升级 - 伪类/伪元素不参与层级计数：
.btn { &:hover { &::before { content: "★"; } } }看似三层，实际编译为.btn:hover::before（0-2-1），安全 - 媒体查询必须用
@at-root跳出：.btn { @at-root @media (min-width: 768px) { &--large { font-size: 18px; } } }，避免生成@media { .btn .btn--large { } }
最常被忽略的一点：性能瓶颈往往不出现在“写了什么”，而出现在“改了什么”。一旦某处嵌套失控，后续每次调整都得绕着权重走，!important就成了默认选项。
