Less嵌套过深会导致CSS选择器爆炸、性能下降和维护困难，建议控制在2层以内并采用BEM命名法替代深层嵌套，避免伪类/伪元素过度嵌套，用工具检测选择器深度。
Less嵌套过深会导致CSS选择器爆炸
Less里写5层嵌套，编译出来可能生成带10个类名的长选择器，比如 .header .nav .item .link .icon:hover。浏览器匹配这种选择器要逐级回溯，性能明显变差，尤其在老设备或复杂DOM中。
更麻烦的是，这类选择器优先级高得离谱，后续想用简单规则覆盖它，基本得靠!important硬顶，维护成本陡增。
- 嵌套每多一层，编译后选择器长度至少+1个层级，3层嵌套常见，4层以上就该警觉
- 避免在
&内部再用&做二次嵌套，比如& { &__elem { ... } }——这等于主动制造深度 - 组件级样式建议控制在2层以内：外层BEM块名 + 元素/修饰符，如
.card {}和.card__title {}
用BEM替代深层嵌套是更可持续的写法
Less本身不强制BEM，但它是对抗嵌套膨胀最直接的工程实践。把视觉结构映射到类名上，而不是靠缩进表达父子关系，编译结果干净，人也容易定位样式来源。
比如一个按钮组件，别这么写：
.btn {
padding: 8px;
&--primary {
background: blue;
&:hover {
background: darkblue;
&::before {
content: "★";
}
}
}
}
而应拆成语义清晰、扁平的类名：
.btn { padding: 8px; }
.btn--primary { background: blue; }
.btn--primary:hover { background: darkblue; }
.btn--primary:hover::before { content: "★"; }
-
&--primary这类修饰符写法没问题，但&:hover里再套&::before就跨了三层，实际等价于.btn--primary:hover::before，完全可单独写 - BEM不禁止嵌套，只反对“为嵌套而嵌套”。用
@import按模块拆文件，比在单个Less里堆6层&更利于协作 - 如果必须保留嵌套（比如主题色切换），用
html[data-theme="dark"]这类顶层开关，比.theme-dark .component .item更可控
编译前检查选择器深度的实操方法
Less本身不报嵌套警告，得靠外部工具或人工卡点。最轻量的方式是在编译命令后加一道CSS分析。
- 用
postcss-selector-max-specificity插件，在Webpack或Vite构建流程中拦截超限选择器（比如 specificity > 0,2,0） - 本地开发时，运行
npx lessc input.less | grep -E "\.[a-z]+(\s+\.[a-z]+){3,}"快速扫出含4个及以上类名的选择器 - VS Code装
Less IntelliSense插件，它会在嵌套超过3层时标黄提示，虽然不阻止编译，但能即时反馈
伪类和伪元素嵌套最容易失控
&:hover、&::before看着只是加个状态，但和父级嵌套一结合，就会悄无声息拉长选择器链。比如.modal .content &::after编译后是.modal .content .modal .content::after——重复了，而且根本没必要。
- 伪类/伪元素尽量写在最末级，不要裹在多层
&里；.btn:hover比.container .btn:hover安全得多 - 避免
&:not(.disabled) &::before这种嵌套否定，它会生成冗余选择器，且兼容性在IE中极差 - 动画关键帧
@keyframes别放进嵌套块，它不属于CSS选择器范畴，放里面纯属语法污染
编译后的选择器长度和层级，不是看Less源码缩进有多漂亮，而是看浏览器DevTools里Computed Styles里那个真实选择器字符串有多长——那里才是真相所在。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
