SCSS嵌套超3层会降低CSS性能，因浏览器从右往左解析选择器，深层嵌套增加计算量、升高特异性、导致语义混乱和冗余代码。
SCSS嵌套超过3层为什么会让CSS选择器变慢
浏览器解析CSS选择器是从右往左匹配的，嵌套过深（比如 .header .nav .item .link:hover）会显著增加计算量，尤其在重绘频繁的页面中。SCSS本身不生成运行时开销，但过度嵌套直接产出低效CSS——这不是编译问题，是选择器设计问题。
- 每多一层嵌套，生成的选择器特异性（specificity）就升高一级，容易引发意外交互和覆盖困难
- 编译后类名可能冗长且不可预测，比如
.component__list .component__list-item .component__list-item-link，实际只需.component__list-link - 开发者倾向用嵌套“模拟HTML结构”，但CSS应基于功能/状态组织，而非DOM树深度
用@at-root提前跳出嵌套来控制输出结构
当必须在嵌套上下文中写兄弟类或工具类时，硬撑嵌套只会让CSS膨胀。@at-root能强制把某段样式提级到顶层，避免无意义的父选择器拼接。
.card {
padding: 1rem;
&__title {
font-size: 1.25rem;
}
&__body {
color: #333;
// 这里想加一个独立的高亮状态，不依赖.card结构
@at-root .card--highlighted & {
background: #fff8e1;
}
}
}
编译结果是 .card--highlighted .card__body，而不是 .card .card--highlighted .card__body——后者多了一层无效约束，且语义混乱。
用#{&}拼接类名比嵌套更可控
需要生成 BEM 风格的修饰符（如 .btn.btn--primary）或响应式变体（如 .grid.grid--sm）时，直接嵌套会产出 .grid .grid--sm（空格分隔，变成后代选择器），完全错误。
立即学习“前端免费学习笔记（深入）”；
- 用
&--sm生成.grid--sm（推荐，简洁） - 用
#{&}--sm显式拼接，适合动态场景，比如$breakpoint: 'md'; #{&}--#{$breakpoint}→.grid--md - 避免
& .grid--sm这种写法：空格意味着后代选择器，不是并列类名
哪些场景其实根本不需要嵌套
SCSS嵌套常被误当作“组织代码”的手段，但它解决的是选择器复用，不是文件结构。以下情况建议扁平书写：
- 工具类（
.text-center,.d-flex）：它们本就不该依赖上下文 - 组件修饰符（
.button--large）：和基类.button是平行关系，不是父子 - 媒体查询内部规则：在
@media (min-width: 768px)里再嵌套一层选择器，等于给每个断点都复制一遍深层结构 - 伪类组合（
a:hover::before）：嵌套&:hover::before没问题，但若前面还套了三层容器，最终选择器就是.layout .main .content a:hover::before，毫无必要
真正难的不是写嵌套，是判断哪一层嵌套提供了明确的语义边界——比如 .modal__header 和 .modal__body 共享 .modal 上下文是合理的；但 .modal .overlay .backdrop .fade 就是典型的路径式思维，应该拆成独立、可复用的类。
