SCSS嵌套本身不触发警告，真正被警告的是编译后CSS选择器特异性过高或复合选择器超限（如Stylelint的selector-max-compound-selectors规则），常见于深层嵌套、空格误用&导致后代选择器膨胀、混用@nest语法不兼容及BEM结构失控等情况。
SCSS嵌套本身不会触发警告，真正被警告的是编译后生成的CSS选择器特异性（specificity）过高或层级过深——这通常来自工具链（如Stylelint、ESLint插件或PostCSS插件）的规则拦截。
为什么Stylelint报“selector-max-compound-selectors”错误
这是最常见的嵌套警告来源。它不关心你写了多少层@nest或大括号，而是检查最终CSS中单个选择器里“复合选择器”的数量（即由空格、>、+、~连接的独立部分）。
-
.card .header .title span→ 4个复合选择器（.card / .header / .title / span），超默认阈值3 -
.card > .header__title:hover→ 3个（.card / .header__title / :hover），刚好卡线 - SCSS里写
.card { .header { .title { span { ... } } } }，编译后就是上面第一种，直接触发警告
&符号误用导致意外的后代选择器
很多人以为&.is-active和& .is-active只是空格差异，但它们语义完全不同，且后者极易引发深层嵌套警告。
-
&.is-active→ 编译为.btn.is-active（同元素多类，安全） -
& .is-active→ 编译为.btn .is-active（后代选择器，深度+1，易踩线） - 在
.modal { & .overlay { ... } }里，& .overlay实际等价于.modal .overlay，而如果.modal本身已嵌套在.page下，就变成.page .modal .overlay，三层复合 - 想选子元素？用
> .overlay更明确，也更可控
原生@nest和SCSS嵌套的兼容性陷阱
CSS Nesting规范要求所有嵌套必须显式带&，而SCSS默认允许省略——混用时容易漏掉@nest，导致样式泄漏或编译失败。
立即学习“前端免费学习笔记（深入）”；
- 写
.card { h2 { color: red; } }在纯CSS Nesting中是非法的（缺少&），浏览器会忽略整条规则 - 正确写法是
.card { @nest & h2 { color: red; } } - 若项目同时支持SCSS和原生CSS Nesting（比如通过PostCSS插件），没加
@nest的块会被当作全局选择器处理，h2可能污染全局 - 建议：统一用SCSS就关掉CSS Nesting插件；转向原生就禁用SCSS嵌套，全部改用
@nest语法
嵌套超过3层时，BEM命名反而更轻量
当发现必须写.sidebar .list .item .link:hover才能命中目标，说明结构已经失控——这时候强行嵌套不如拆成独立BEM块。
- 把
.sidebar__list-item-link单独定义，而非依赖四层嵌套 - BEM类名自带语义层级，不需要靠嵌套“模拟DOM”，也避免
!important或覆盖战 - SCSS嵌套只应服务BEM：例如
.card { &__title { ... } &:hover { ... } }，严格限制在容器、元素、状态三层内 - 真正难控的不是嵌套语法，而是团队对“这个样式到底属于谁”的认知分歧——没有命名约束的嵌套，等于给未来埋雷
最常被忽略的一点：嵌套深度警告往往出现在CI阶段，本地开发却看不到。因为工具链配置没同步到编辑器插件，或者.stylelintrc里没开selector-max-compound-selectors实时校验。上线前才爆红，代价远高于写代码时多按两下Tab。
