less嵌套过深本身不慢，但编译出的深层后代选择器（如.page .main .content .card .title）会导致浏览器匹配变慢、权重失控、调试困难；应改用bem命名与正确使用&避免冗余层级。
Less嵌套过深本身不慢，但编译出的选择器会让浏览器匹配变慢、权重失控、调试困难——问题不在Less，而在你让它生成了 .page .main .content .card .title 这类5层选择器。
浏览器为什么怕深层后代选择器
浏览器解析CSS时严格从右往左回溯：.card .title 先找所有 .title，再逐个查父级是不是 .card；每多一层，就多一跳向上检查。DOM节点越多，匹配开销越呈指数增长。
- 实测显示，
.a .b .c .d .e在低端安卓 WebView 中样式重算（Recalculate Style）耗时比.e或.card__title高4倍以上 - DevTools Performance 面板里 “Recalculate Style” 时间突然飙升，大概率就是这类选择器在拖后腿
- 伪类写在最右边（如
.card .title:hover）会触发全量扫描，比.title--hovered多2–3倍成本
怎么用 & 写对嵌套，而不是写崩
& 是父选择器的完整副本，不是缩进占位符——用错等于主动加权、制造冗余。
- ✅ 安全写法：
.btn { &__icon { display: inline-block; } }→ 编译为.btn__icon（权重 0-1-0） - ✅ 安全写法：
a { &:hover { color: blue; } }→a:hover（权重 0-1-1），伪类不增加层级计数 - ❌ 危险写法：
.modal { & .close { opacity: 0.5; } }→.modal .close，多一层无意义后代关系，权重+1 - ❌ 危险写法：
.list { & li { margin: 4px; } }→ 实际仍是.list li，&没起作用
重构老旧Less代码的实操路径
别指望 @at-root 救命——它解决的是“不该被嵌套却被动嵌套”的问题，不是给4层缩进打补丁。
- 用
grep -E "\.[a-z]+(\s+\.[a-z]+){3,}"扫一遍编译输出，命中即说明存在 ≥4 个类名串联的选择器，必须处理 - 遇到
&__item &__icon &::before这种，立刻拆成独立 BEM 类：.btn__icon、.btn__icon::before - 禁止在
&内部再用&做二次嵌套，例如& { &__elem { } }—— 这等于主动制造4层选择器 - 布局类（如
.row、.col）禁用嵌套，它们本就不该承担样式逻辑 - 媒体查询别塞进深层嵌套：
@media (max-width: 768px) { .nav { & a {} } }才对；漏掉&就会输出全局a
容易被忽略的编译后陷阱
Less源码看着干净，不代表输出CSS可控——很多性能问题只在编译后暴露。
- 运行
lessc --lint可自动标出嵌套 >3 层的位置 - 用 Chrome DevTools 的 “Coverage” 面板查未用CSS，常会发现大量
.page .layout .main .content .text p类似长链，根源就是嵌套失控 -
extend()和嵌套混用极易产生冗余：比如.icon { &:extend(.visually-hidden all) }在嵌套块里使用，Less 会把.visually-hidden的所有规则都复制进当前上下文 - 禁用浏览器端编译——开发期用
lessc预编译，避免 runtime 解析拖慢首屏
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
