4层CSS选择器是实测性能临界点，浏览器从右往左匹配需逐层回溯祖先，DOM越深、动态越频繁，Recalculate Style耗时越易超20ms导致掉帧。
嵌套超过3层时，CSS选择器匹配性能会明显下降，不是“看起来卡”，而是滚动、悬停、动画时真卡——4层就是实测临界点。
浏览器从右往左匹配选择器，每多一层就多一次祖先回溯
比如 .layout .sidebar .nav .item .link 这种5层写法，浏览器要：先找所有 .link 元素 → 对每个 .link 检查父级是否为 .item → 再查 .item 的父级是否为 .nav → 依此类推。DOM越深、节点越动态（如虚拟滚动），这个回溯链消耗的CPU越多。
- 低端Android设备上，4层已触发明显卡顿；5层以上，DevTools里
Recalculate Style耗时常飙到90%+ - Lighthouse报
Avoid overly specific selectors，根源就在这儿 - 不是编译慢，是运行时匹配慢；Sass再快，也救不了生成的长选择器
& 符号误用会让问题更隐蔽
& 只认紧邻上一层的选择器字符串，跟缩进无关。有无空格，输出天差地别：
- 有空格：
.card { .header { &__title { } } }→ 编译出.header__title（&指向.header，不是.card） - 没空格：
.card { &__header { &__title { } } }→ 编译出.card__header__title（但BEM禁止Element嵌套Element） - 更糟的是：如果HTML里没写
class="header"，这条规则根本不会生效，但开发者常误以为是“样式没加载”，反复加!important
@extend 在深层嵌套中会放大冗余
@extend 不是复用，是编译期机械拼接选择器。一旦嵌套已深，它会让选择器长度翻倍：
立即学习“前端免费学习笔记（深入）”；
- 写在
.layout .dashboard下的.modal和.card都@extend %flex-center，结果生成：.layout .dashboard .modal, .layout .dashboard .card { display: flex; } - 多个组件共用同一占位符时，逗号分隔列表爆炸式增长，CSSOM构建时间显著上升
-
%placeholder必须以%开头，且不能出现在嵌套规则内部（如.card { .title { @extend %heading; } }是危险操作）
真正该停手的信号不是“写不下去”，而是语义断裂
当嵌套开始服务于“DOM位置”而非“语义职责”时，就是重构信号：
- 组件需要被多个不相关容器复用（比如
.tooltip出现在.header和.table-cell里） - 内部有2个以上需独立开关的状态（
is-open/is-error/is-loading） - JS频繁动态增删class（React/Vue中className绑定逻辑复杂）
- 写
div > ul > li > a这类模拟DOM路径的嵌套？直接换成.nav-link语义类名
最常被忽略的一点：不是嵌套本身错，而是你靠缩进“猜”& 指向哪一层——VS Code里按住Ctrl点击编译后的CSS文件，直接看生成结果，比读SCSS缩进可靠得多。
