嵌套超过3层会显著拖慢浏览器样式计算、导致覆盖困难、增加调试成本。因CSS选择器从右往左匹配，深层嵌套引发大量向上验证；Sass重复输出长链选择器，特异性过高；&作用域易误判；应优先用BEM、@at-root、>子选择器及自定义属性优化。
嵌套过深不是“写得不够优雅”的问题，而是会直接拖慢浏览器样式计算、导致覆盖困难、增加调试成本的真实性能瓶颈。超过3层嵌套就该干预，5层以上基本必须重构。
为什么嵌套层级超过3层会显著影响性能
浏览器匹配CSS选择器是**从右往左**执行的。.page .main .content .card .title这种5级选择器，意味着浏览器要先找所有.title元素，再逐层向上验证其是否在.card内、是否在.content内……DOM越深、动态更新越频繁，耗时越明显。这不是理论风险——DevTools的“Recalculate Style”面板里能直接看到飙升的耗时，Lighthouse也会报“Avoid overly specific selectors”。
- 每多一层嵌套，Sass就复制一次父选择器前缀，相同结构被复用多次时，输出中会出现大量重复长链
- 深层嵌套生成的选择器特异性（specificity）极高，后期想用
.title统一改色几乎不可能，只能加!important或更长选择器硬怼 -
&的作用域只认最近一层父选择器，多层嵌套下极易误判拼接结果，比如.card { .header { &__title { } } }编译出的是.header__title，而非预期的.card__title
用@at-root和BEM主动跳出嵌套
别让嵌套服务于HTML结构深度，而要服务于组件语义边界。遇到.card .header .title这类写法，第一反应不应该是继续缩进，而是判断：这个.title是否真的依赖于它在.card里的位置？如果不是，就该用BEM扁平化。
- 把
.card { .header { .title { ... } } }改成.card__title { ... }，配合HTML中显式书写class="card__title" - 用
@at-root提前拉出本该平级的规则：.card { @at-root .card--compact { padding: 0.5rem; } }，避免编译出.card .card--compact - 子选择器
>比后代选择器（空格）更可控：.card > .header明确切断继承链，也避免生成冗余长选择器
慎用@extend，优先用%placeholder + 自定义属性
@extend不是复用，是选择器合并。滥用它会让CSS体积爆炸，尤其多个组件共用同一基础类时，会生成.a, .b, .c { display: flex; }这类逗号分隔列表，增大CSSOM构建压力。
立即学习“前端免费学习笔记（深入）”；
- 只对无状态、无上下文、可直接加到HTML的原子行为使用
%placeholder，例如%sr-only、%clearfix - 禁用含
:hover、@media、&__header结构的占位符——它们必然导致冗余输出 - 把间距、颜色、圆角等视觉值抽成CSS自定义属性：
:root { --space-sm: 0.5rem; }，组件内统一用margin: var(--space-sm) - 跨文件
@extend必须配合@use并带上命名空间：button.%base，否则编译报错Undefined placeholder selector "%xxx"
构建链路必须补上PurgeCSS和深度检测
--style=compressed只删空格换行，对选择器爆炸完全无效。真正有效的瘦身发生在编译前和编译后两个环节。
- 用
sass-nesting-analyzer插件在CI或编辑器里实时检测嵌套深度，设阈值为3层，超限自动告警 - 在
package.json中声明"sideEffects": ["*.scss"]，告诉Webpack这些只是样式，可安全tree-shaking - PurgeCSS必须放在Sass编译之后、CSS压缩之前；
content字段要覆盖所有模板路径，漏一个src/components/Modal.vue，整套Modal样式就全保留在最终CSS里 - 跳过框架入口文件，手动
@use子模块：@use "bootstrap/scss/functions"，而不是@import "bootstrap"
最常被忽略的点是：嵌套本身不提供作用域隔离。你以为.modal { .header { ... } }锁住了样式，其实只是生成了更长的选择器，照样会被外部高权重要素覆盖。真正的隔离靠@use文件拆分 + BEM类名显式声明，而不是靠缩进制造的幻觉。
