less嵌套会生成冗余选择器链，导致权重暴增、体积膨胀、ast爆炸及调试失效；应限制嵌套≤3层，优先用bem命名与平级结构，避免递归无约束膨胀。
嵌套直接生成冗余选择器链
Less嵌套不是语法糖，它会忠实展开成完整的选择器组合。比如 .card { .header { h1 {} } } 编译后是 .card .header h1，而不是 .card__header h1。一旦嵌套超过 3 层，选择器权重和字符数就指数级增长；更糟的是，多个组件共用同一父类（如 .page）时，.page .layout .main .content .title 这类 0-4-0 权重的选择器会被重复生成多次，gzip 前体积翻倍很常见。
嵌套 + @import 链式叠加放大爆炸效应
当嵌套规则分散在多个文件中，并通过 @import 组合时，Less 不会去重或合并路径，而是把每一份嵌套结构原样拼接。例如：
// a.less
.container { .box { color: red; } }
// b.less
@import "a.less";
.container { .item { font-size: 14px; } }
最终输出会包含两组独立规则：.container .box 和 .container .item，但若 a.less 被 c.less、d.less 也导入，.container .box 就会重复出现三次——而 Less 默认不识别这是同一段逻辑。
- 用
@import (once)只能防文件重复加载，无法阻止嵌套结构被多次展开 - 嵌套层级 >15 层时，AST 节点数常超 10 万，直接触发 JavaScript heap out of memory
- Webpack 中若 style-loader 在开发期把所有嵌套 less 打进 JS bundle，热更新时 AST 会持续累积不释放
嵌套掩盖了本该用 BEM 或 mixin 解决的问题
开发者常误以为“写得深=结构清晰”，结果用嵌套替代命名规范。真实问题在于：嵌套本身不提供语义，也不控制作用域。你写 .modal { .overlay { .content { .header {} } } }，编译出的选择器既难搜索、又无法单独复用，还导致 CSS 规则无法被构建工具 Tree Shaking。
- 应改为平级 BEM 类：
.modal__overlay、.modal__content、.modal__header，再用&__overlay等嵌套语法收口，保证编译后仍是单类名 - 状态组合（如
&--hover）可安全嵌套，但媒体查询必须提级写，否则同一段样式会在每个断点里复制一份 - 超过 3 层嵌套时，Chrome DevTools 已无法准确定位源码位置——这不是调试问题，是结构失控的信号
递归 mixin 混合嵌套会让内存崩溃提前到来
看似简洁的递归写法，比如 .gen(@n) when (@n > 0) { .gen((@n - 1)); }，一旦嵌入嵌套块内（如 .card { .gen(20); }），Less 会为每一层递归+每一层嵌套创建独立 AST 节点。节点数不是线性增长，而是呈 O(n²) 甚至更高阶膨胀。Less 3.9.x 版本对此毫无回收机制，升级到 less@^4.2.0 后内存占用下降 40%+，但前提是你已把嵌套压平、递归加了终止上限。
- 禁用无约束的
when (@i > 0)，改用when (@i >= 1) and (@i = - 避免在递归体里调用
unit()、percentage()或动态拼接选择器（如~".col-@{i}"） - 深度嵌套 + 递归 mixin + 动态变量三者混合时，调大 Node.js 内存只是拖延崩溃，重构才是唯一解
真正棘手的从来不是“要不要嵌套”，而是嵌套之后有没有人检查最终 CSS 里是否出现了大量孤立、重复、高权重的选择器——那才是体积暴增和首屏变慢的源头。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
