less嵌套过深导致权重失控、性能下降和调试困难：每层编译为后代选择器（如.card .header .title权重0-3-0），浏览器从右向左回溯匹配，4层即卡顿；应改用bem单类名（如.card__title）和@at-root提级，而非依赖&补救。
Less嵌套过深不是“写得细”，而是把样式逻辑绑死在 DOM 结构上，一旦 HTML 微调，CSS 就断；更关键的是，它让权重、性能、调试三者同时恶化，且问题会随项目增长指数级放大。
编译后选择器权重失控，覆盖靠猜和!important
嵌套每多一层，就给选择器加一个后代关系（空格），权重直接+1。比如 .card { .header { .title { color: red; } } } 编译出 .card .header .title（权重 0-3-0），而你只想改标题颜色，却得写 .card .header .title.is-highlight 或硬加 !important——这不是覆盖，是妥协。
- 伪类如
:hover不增加层级计数，但& .icon这种带空格的写法会，等于白加一层 -
&__elem是安全的，它生成单类名（.btn__icon），权重恒为 0-1-0 - VS Code 里缩进到第 4 层时，IntelliSense 会标黄——不是提醒“还能忍”，是告诉你“现在重构成本最低”
浏览器匹配变慢，滚动/悬停都卡顿
浏览器从右往左匹配选择器：.page .main .content .card .title 会先找所有 .title，再逐个向上检查父级是否存在。DOM 节点越多（比如商品列表有 200 个 .title），这个回溯过程就越耗 CPU。
- 实测：在低端 Android WebView 中，4 层选择器的
Recalculate Style时间比 2 层高 3–5 倍 - 高频更新区域（如滚动列表项）只要含空格选择器，每次 layout 都重跑整条匹配链
- Lighthouse 报 “Avoid overly specific selectors”，根源常就在这类嵌套
DevTools 调试失效，改了样式却看不到效果
权重高 + 选择器长 = DevTools 的“已计算样式”面板里，真正生效的规则被压在十几条被覆盖的旧规则底下。你点中一个 .title，看到的可能是 .card .body .header .title 的旧值，而不是你刚改的那行。
- Chrome 的 Coverage 面板常扫出大量未用 CSS，其中
.layout .main .content .text p这类长链，基本就是嵌套失控的证据 - VS Code 的 CSS Peek 功能对深层嵌套支持弱，Ctrl+点击常跳错位置，甚至停在空行
- 用
@at-root抽媒体查询或伪类是正解，但它不解决已写完的 4 层嵌套——那是掩盖，不是修复
真正卡住人的，不是不会用 & 或 @at-root，而是嵌套写多了，忘了自己正在生成选择器。.a .b .c .d 看着像局部作用域，实际是全局高压线，而且浏览器每次渲染都在默默回溯它。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
