嵌套超过3层会导致CSS选择器权重失控、浏览器匹配变慢、调试困难；浏览器从右往左逐级回溯匹配，DOM越深耗时越长，低端设备中可能慢3–5倍，Recalculate Style时间明显上涨。
嵌套超过3层时，CSS选择器权重失控、浏览器匹配变慢、调试困难——这不是风格偏好问题，是真实可测的性能退化。
浏览器如何匹配深层嵌套选择器
Less 编译不改写匹配逻辑，它只生成更长的选择器。比如 .page .layout .main .content p 这种 4 层后代选择器，浏览器必须从右往左逐级向上回溯：先找所有 p，再检查父元素是否为 .content，再往上验 .main……DOM 越深、节点越多，这个过程越耗时。
- 老设备或低端安卓 WebView 中，匹配耗时可能高出 3–5 倍
- Chrome DevTools 的 “Rendering” 面板里，
Recalculate Style时间明显上涨 - 用
npx lessc input.less | grep -E "\.[a-z]+(\s+\.[a-z]+){3,}"可快速扫出含 4+ 类名的选择器
三层嵌套为什么是临界点
0-3-0 权重（如 .card .header h1）已是常见覆盖上限。再加一层，变成 0-4-0，后续想用单个类名（如 .h1-emphasis）覆盖它，就必须写成 .h1-emphasis, .card .header h1 或加 !important —— 实际等于放弃样式可维护性。
- 三层内（如
.btn { &--primary { &:hover { ... } } }）编译为.btn--primary:hover，权重恒为 0-2-1，安全 - 四层起（如
.modal { .overlay { .content { h1 { ... } } } }）必然产出 0-3-1+ 权重，且无法靠 BEM 降权 - VS Code 的 Less IntelliSense 插件会在第 4 层缩进处标黄，这是最轻量的实时拦截方式
怎么把深层嵌套“拆平”又不丢语义
不是删嵌套，而是换表达方式。BEM 不是命名规范，是结构映射工具：把 DOM 深度转成类名语义，而非靠缩进模拟。
立即学习“前端免费学习笔记（深入）”；
- 把
.card { .body { .title { color: red; } } }改成.card__title { color: red; } - 伪类/伪元素不参与层级计数：
.btn { &:hover { &::before { ... } } }看似三层，但编译后是.btn:hover::before，仍属 0-2-1 权重 - 媒体查询必须用
@at-root跳出嵌套：.btn { @at-root @media (min-width: 768px) { &--large { font-size: 18px; } } }，避免生成@media { .btn .btn--large { ... } } - 共用样式抽成 Mixin，但别在嵌套里反复调用：
.card { .text-style(); }比.card { .title { .text-style(); } .subtitle { .text-style(); } }更干净
构建流程中如何自动拦截超限嵌套
人工卡点容易漏，得让工具链说话。Less 本身不报错，但 PostCSS 可补位。
- Webpack/Vite 中接入
postcss-selector-max-specificity，设阈值为0,2,0，超限直接构建失败 - CI 流程加一行：
grep -r "\.[a-z]\+.*{" src/styles/ | grep -E "{.{12,}"，粗筛缩进过深的行（12+ 空格基本对应 4 层+） - 禁用
extend()与嵌套混用：.icon { &:extend(.visually-hidden all) }在嵌套块里会复制整套规则，导致选择器爆炸
真正难的不是发现嵌套过深，而是在动效、主题、响应式交织的组件里，判断哪一层该保、哪一层该拆。这时候看编译后的 CSS 文件比看 Less 源码更管用——所有空格数 > 6 的行，都该被当作待办事项处理。
