咱们开门见山，先说一句大实话：Sass嵌套本身并不直接等于模块化，但它绝对是实现模块化布局的关键支撑手段。真正让样式变得可维护、可复用的，是嵌套 + 命名规范 + 文件拆分 + 作用域控制这套组合拳。下面咱们就来拆解一下，这套拳法怎么打才能又快又稳。
嵌套层级怎么写才不破坏模块边界
嵌套，反映的是组件内部的结构关系，而不是整个HTML的DOM树全局坐标。举个例子，写一个.card组件，它的.card__title和.card__body就应该安心地嵌套在.card下面，而不是跟着页面里所有的h2或div乱跑。
常见的问题有哪些呢？
- 写出
article .card h2 { ... }这种强耦合父级的选择器，结果组件从section .card里挪到别的地方就用不了。 - 嵌套超过4层，比如
.page .main .content .card .header .title，编译完的选择器权重高得吓人，后期想覆盖简直得求神拜佛。 - 直接用标签名嵌套（像
ul li a），哪天HTML结构一调整，把ul换成nav，样式立刻就崩。
正确的做法是什么？其实很简单：
- 以BEM命名的块（比如
.card）作为嵌套的根节点。 - 只嵌套它的直接子元素（
&__title、&__body）和修饰符（&--featured）。 - 伪类统一用
&:hover、&:focus，千万别写成li:hover a这种似是而非的东西。
@use + 嵌套：如何让每个组件文件真正自包含
光有嵌套还不够，必须配合@use来隔离作用域。否则变量、mixin满天飞，全局污染，一个组件改了两个跟着遭殃。
你看这个示例目录结构：
_components/
_card.scss
_button.scss
styles.scss在_card.scss里，通过@use引入依赖，然后用嵌套来组织样式：
@use 'variables' as v;
@use 'mixins' as m;
.card {
border: 1px solid v.$border-color;
@include m.responsive-padding;
&__title {
color: v.$heading-color;
}
&--compact {
padding: v.$spacing-sm;
}
}这里的关键点在于：
@use引入后，不会把_card.scss里的变量泄露到全局。其他文件想用，必须自己再@use一遍。- 所有依赖（颜色、间距、响应式逻辑）都来自模块导入，杜绝硬编码值。
- 编译后，
.card__title这个CSS规则就乖乖待在.card模块内，绝不会阴差阳错地影响到其他地方的h2。
嵌套中 & 的误用：为什么 hover 总是不起作用
这大概是入坑Sass后踩得最多的一个坑：忘了用&，结果生成了后代选择器，把自己给绕进去了。
错误写法长这样：
.btn {
background: blue;
:hover { color: white; } // 编译出来是 .btn :hover → 匹配.btn内所有元素的hover状态
}正确姿势应该是这样：
&:hover→ 编译出.btn:hover&.is-active→ 编译出.btn.is-active.btn-group &→ 编译出.btn-group .btn（用于从外部上下文覆盖内部样式）
注意，&必须紧贴着选择器，中间不能有空格。多个&连用的情况极少出现，除非你真的需要。
嵌套和性能：为什么深层嵌套会让CSS体积变大
每多一层嵌套，选择器长度和匹配开销就跟着往上涨。Sass编译时不会替你去压缩选择器，像 .layout .sidebar .nav .item .link:hover 这种输出，不光维护起来头疼，浏览器渲染时也得额外费力气。
从实测数据来看：
- 嵌套到5层以上，编译后的CSS文件体积平均会膨胀18%~25%。
- 打开Chrome DevTools的“Rendering”面板，这类选择器的style recalc时间会明显升高。
- 在移动端低端设备上，复杂的嵌套样式甚至可能触发强制同步布局，把渲染线程拖死。
结合实战经验，推荐这么干：
- 严格将嵌套控制在3层以内（
.component→&__element→&:hover）。 - 用
@extend代替重复样式，但只用在语义一致的类之间（比如.btn和.btn-primary）。 - 动态状态（比如
data-state="loading"）优先用属性选择器[data-state="loading"]搞定，不靠嵌套去推导。
真正考验功力的，从来不是怎么写嵌套，而是判断哪一层该停——要停在组件边界，而不是DOM深度。一旦你开始觉得“这个div里面还要再包一层span，得再写一层嵌套”，那就该考虑拆文件了。
