嵌套过深会显著降低CSS性能，因后代选择器需从右往左逐级回溯匹配，超3层后样式计算时间平均涨40%以上；应避免深层嵌套、布局类嵌套及错误空格使用，并通过构建流程强制卡控深度。
因为嵌套中一个空格就生成后代选择器，而浏览器匹配它是从右往左逐级回溯的——DOM越深、节点越多，耗时越长，实测超3层后样式计算时间平均涨40%以上。
为什么.card { .title { color: red; } }比.card__title慢
前者编译为.card .title，浏览器先找所有.title元素，再挨个查父级是否为.card；后者是单类名.card__title，直接哈希查找。低端安卓 WebView 中，前者可能慢3–5倍。
- 搜索编译后 CSS 里含
{前4个及以上空格的行，基本对应3层以上嵌套 -
lessc --lint能标出嵌套超限位置，但默认不启用，需手动加--lint参数 - Chrome DevTools 的 Performance 面板里
Recalculate Style时间突然飙升，大概率就是这类选择器在拖后腿
&不是万能的，用错空格反而加重性能负担
&只控制拼接逻辑，不改变匹配行为。写& .active会输出.btn .active（后代），而&.active才是.btn.active（同元素双类）。
- 危险写法：
.dropdown { & .menu-item { } }→ 编译为.dropdown .menu-item，污染全局、无法局部复用 - 安全写法：
.btn { &__icon { } }→.btn__icon，权重恒为 0-1-0 - 伪类可用：
a { &:hover { } }→a:hover，权重 0-1-1，不算新增层级
媒体查询和布局类嵌套最容易放大性能问题
把@media塞进嵌套块里，或对.row/.col这类布局类使用嵌套，会导致选择器重复膨胀、权重失控，且无法被 PurgeCSS 安全剔除。
立即学习“前端免费学习笔记（深入）”；
- 错误：
.nav { @media (max-width: 768px) { li { a { } } } }→ 每条规则都带.nav前缀 - 正确：
@media (max-width: 768px) { .nav li a { } }或用@at-root抽离：.nav { @at-root @media (max-width: 768px) { &__item { } } } - 布局类禁止嵌套：
.row和.col本就不该承担样式逻辑，嵌套只会让选择器变重、语义变模糊
真正容易被忽略的是：嵌套深度控制不能靠经验或自觉，必须进构建流程卡死。CI 里加一行grep -r "\.[a-z]\+.*{" src/styles/ | grep -E "{.{12,}"，12+空格基本对应4层缩进——漏掉一次，上线后滚动帧率可能掉15%。
