SCSS中可用嵌套群组选择器（如.container { h1, h2, h3 { ... } }）避免重复父名，提升可读性与维护性；逗号必须顶格写于大括号内；关系选择器（~、>、+）需紧贴父选择器；不可用@extend替代嵌套分组；嵌套建议不超过三层，过深易致性能下降与特异性失控。
SCSS里怎么用嵌套写群组选择器
直接在父选择器块内用逗号分隔多个子选择器，就能避免重复写父名。比如你想让 .container 下的 h1、h2、h3 共享同一行高，别这么写：
.container h1, .container h2, .container h3 { margin-bottom: .8em; }
改用嵌套写法更干净：
.container {
h1, h2, h3 {
margin-bottom: .8em;
}
}
编译后结果一样，但源码可读性高、修改成本低。注意：逗号必须顶格写在大括号内部，不能缩进到下一行再写——某些老版本 Sass 解析器会报错或忽略。
嵌套时怎么处理兄弟/子元素组合选择器
像 article ~ article、article > footer 这类带关系符的选择器，SCSS 允许把 ~、>、+ 放在嵌套块内部，紧跟在父选择器后面。
立即学习“前端免费学习笔记（深入）”；
常见错误是硬套“子元素”思维，以为必须写成 article { ~ article { ... } } ——其实语法不支持这样，~ 必须紧贴父选择器，中间不能换行或加空格。
- 正确写法：
article { ~ article { border-top: 1px dashed #ccc; } > footer { background: #eee; } } - 错误写法：
article { & ~ article { ... } // 多余的 &，编译出 .article .article ~ .article - 如果需要同时作用于多个父级（如
section和article），得用群组写法：section, article { ~ & { ... } // 注意这里 & 指代的是当前群组中的每个父选择器
@extend %placeholder 能不能替代嵌套分组
不能混用。嵌套分组解决的是「结构复用」问题，@extend %placeholder 解决的是「声明复用」问题。前者产出的是多个独立选择器，后者是合并选择器链。
比如你有一组视觉上需要居中的元素：.header、.card-title、.modal-header，它们语义不同但样式一致，这时该用 %text-center：
%text-center {
text-align: center;
}
.header { @extend %text-center; }
.card-title { @extend %text-center; }
.modal-header { @extend %text-center; }
但如果你只是想缩短 .nav a 和 .sidebar a 的写法，就该用嵌套群组：
nav, .sidebar {
a {
color: blue;
}
}
强行用 @extend 会把 a 的上下文拖进来，生成类似 .nav a, .sidebar a 这样的选择器——看起来一样，但一旦嵌套层级变深（比如 .nav ul li a），@extend 就会失控，产出冗长且难以调试的选择器链。
嵌套超过三层就该警惕了
SCSS 不限制嵌套层数，但浏览器解析 CSS 是从右往左的。.layout .main .content .title 这种四层选择器，比 .title 多做三次祖先匹配，尤其在频繁重绘的动画场景下有实际性能影响。
更麻烦的是特异性飙升：.a .b .c .d 权重是 4 类名，而 #header .d 只要 1 ID + 1 类名就能覆盖它——后期维护容易陷入权重战。
- 推荐做法：嵌套控制在三层以内，第四层起强制提取为独立 class，比如把
.card .body .header .title拆成.card-title - 检查编译后 CSS：打开 devtools → Elements → 查看 computed styles 对应的规则来源，确认没生成意外的深层选择器
- BEM 命名能天然约束嵌套深度，比如
.card__title就不该再嵌套.card { &__title { ... } }——这反而增加冗余
真正难的不是写多深的嵌套，而是判断什么时候该停手、抽离、重命名。编译器不会提醒你，但上线后样式冲突和渲染卡顿会。
