SCSS嵌套超3层会引发性能与维护危机：浏览器从右往左匹配时回溯成本激增，5层选择器Recalculate Style耗时超单类名4倍；权重飙升致覆盖困难、DevTools样式变灰、HTML结构调整时样式静默失效；Stylelint需配合stylelint-scss和postcss-scss才有效校验，且应优先用@at-root提级而非加深嵌套。
SCSS嵌套深度超过3层，基本就等于在BEM项目里埋雷——编译出的选择器权重飙升、复用失效、DevTools里样式被压成灰色，而且改HTML结构时样式静默崩坏。
为什么max-nesting-depth设为3或4是硬性底线
浏览器匹配选择器是从右往左回溯的。.card .body .title h2这种4层写法，会让引擎先找所有h2，再逐级验证父级是否满足前3个类名；而.card__title单类名一次哈希查找就命中。实测中，5层嵌套在低端设备上Recalculate Style耗时比单类名高4倍以上。
Stylelint的max-nesting-depth规则只统计真正增加结构复杂度的节点：&、@media、@supports、伪类（如:hover）、伪元素（如::before）。它不数缩进空格，也不数声明块里的换行。
- 设为
3：适合原子化/Utility-First项目（如Tailwind混用），强制组件样式扁平 - 设为
4：更贴近传统封装场景，允许.dialog .dialog__body .dialog__title :is(h1, h2)这类合理组合 - 设为
6或更高：等于放任.layout .sidebar .nav .item .link:hover::before这种脆弱选择器滋生
Stylelint配置必须带customSyntax和stylelint-scss插件
只写"max-nesting-depth": 3在SCSS项目里是无效的——默认解析器不认识&嵌套，也不会把.card { &__title { } }识别为2层深度。
立即学习“前端免费学习笔记（深入）”；
正确配置需显式声明语法和插件：
/** @type {import('stylelint').Config} */
export default {
plugins: ['stylelint-scss'],
customSyntax: 'postcss-scss', // 必须与项目实际语法一致
rules: {
'max-nesting-depth': [3, {
ignore: ['at-rules'], // 允许@media/@supports不计入深度
severity: 'error'
}]
}
};漏掉customSyntax或插件，该规则会静默失效，连报错都不会触发。
遇到真实嵌套需求时，优先用@at-root提级而非加深嵌套
比如需要在.modal上下文中定义.button的暗色主题变体，错误做法是：
.modal {
.button {
@media (prefers-color-scheme: dark) {
color: white;
}
}
}这会产出.modal .button @media (prefers-color-scheme: dark)，且深度已达3层（.modal → .button → @media）。
正确做法是用@at-root切断路径，只保留必要上下文：
.modal {
@at-root (with: .theme-dark) {
.button {
color: white;
}
}
}输出为.theme-dark .button，深度仅2层，语义清晰，且可复用到其他容器中。
特别注意：@media块内禁用&__xxx嵌套。例如@media (min-width: 768px) { .card { &__body { } } }，若外层还有.layout .dashboard，&会展开全部路径，生成6层起步的选择器。
检查编译后CSS是否真被约束住
最终验证点不在SCSS源码，而在生成的CSS文件。打开它，搜索空格连接的类名：
- 出现
.card .card__header：说明用了错误嵌套，不是BEM - 出现
.card .body .title：嵌套超限，且违背BEM“元素必须直属于块”原则 - 出现超过4个连续class空格（如
.a .b .c .d .e）：性能拐点已过，滚动可能卡顿
真正难的不是配对规则，而是每次写&__前停半秒：这个__是不是真属于当前块？还是只是DOM层级的惯性滑动？
