Sass嵌套超3层会导致选择器冗余膨胀、匹配变慢，应使用@at-root跳出嵌套、避免模拟DOM结构、慎用&和@extend，启用source-map调试并定期检查行数变化。
嵌套层级超过3层时，Sass输出体积会明显膨胀
嵌套本身不增加功能，但每多一层，Sass就得多生成一重选择器组合。比如 .card 嵌套进 .section 再嵌套进 .page，最终可能生成类似 .page .section .card 这样的长选择器——它不仅冗余，还拖慢浏览器匹配速度。
实操建议：
- 用
@at-root提前跳出深层嵌套，把本该平级的样式“拉出来”写 - 避免用嵌套模拟 DOM 结构深度，比如
div > ul > li > a这种写法，直接用语义类名（如.nav-link）更可控 - 开启 Sass 的
style: 'compressed'仅压缩空格和换行，不解决选择器冗余问题，别指望它救嵌套滥用
Sass中&符号误用导致选择器重复拼接
& 是父选择器引用，但很多人在嵌套里连用多次，结果生成出意料之外的长选择器。比如：
.btn {
&--primary {
&:hover {
color: red;
}
}
}
这段实际输出 .btn--primary.btn--primary:hover，因为第二个 & 仍指向 .btn--primary，不是原始 .btn。
立即学习“前端免费学习笔记（深入）”；
常见错误现象：
- 样式没生效，检查发现生成的选择器比预期多了一段重复类名
- CSS 文件里出现大量
.x.x:hover、.y.y::before类型的无效重复 - 用
Ctrl+F搜.class.class能快速定位这类问题
@extend 在多个模块间共享时引发选择器爆炸
@extend 看似省代码，但跨文件或跨组件复用时，Sass 会把所有引用它的选择器“合并展开”，最终输出体积可能翻几倍。尤其当基础类（如 %clearfix）被十多个组件 @extend，每个都带不同上下文，结果就是满屏 .header %clearfix, .sidebar %clearfix, .modal %clearfix 式冗余。
替代方案更稳：
- 改用
@mixin+@include，它只复制声明块，不拼选择器 - 把通用样式抽成独立类（如
.u-clear），HTML 里显式加类，反而更轻、更可预测 - 禁用
@extend在@media内部使用——Sass 会把整个媒体查询块复制多遍
未启用Sass的dry-run或source-map调试时，很难定位体积来源
光看 .css 文件看不出哪段 Sass 生成了哪部分 CSS。没有 source-map，你甚至不知道 .list-item:nth-child(2n) 是来自 _list.scss 还是 _grid.scss。
必须做的两件事：
- 构建时加
sourceMap: true（Webpack 的sass-loader或 Dart Sass CLI 的--source-map） - 用 Chrome DevTools 的 “CSS Overview” 面板，勾选 “Show unused CSS”，再结合 source-map 定位哪些嵌套/extend/mixin 实际没被 HTML 引用
- 定期跑
npx sass --no-source-map --style=expanded main.scss | wc -l粗略对比行数变化，比盯着 gzip 后大小更早发现问题
真正难的是判断“该不该删”——有些嵌套看着冗余，其实是为未来组件变体预留的钩子。这时候得翻 Git 历史，看上次修改这个块是谁、为什么加那层 &:focus-within，而不是凭感觉砍。
