Less编译内存溢出主因是AST节点爆炸或递归失控，非物理内存不足；须重构代码：升级Less至3.13.1+/4.2.0+、改递归Mixin为.loop()尾调用、禁用通配@import、压平嵌套选择器、拆解@import链并启用(once)/(reference)/(inline)。
Less编译报 FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory，不是内存不够，而是AST节点爆炸或递归失控；调大Node内存只是拖延崩溃，必须重构代码结构。
为什么加--max-old-space-size不管用
临时扩容（如 node --max-old-space-size=8192 node_modules/less/bin/lessc）只能延缓问题。当嵌套层级超20层、@import链重复加载、或递归.mixin()未设终止条件时，V8堆内存仍会快速耗尽——因为节点数呈指数增长，不是线性增加。
- 检查是否用了
@import "xxx.less"而没加(once)，同一文件被多次解析，AST拷贝多份 - 运行
npx lessc --version，若输出lessc 3.9.0，基本可确认是旧版AST回收缺陷，升级到less@^3.13.1或^4.2.0后内存占用下降40%+ - Webpack项目中
less-loader版本需匹配Less主版本，例如less-loader@7对应less@4，错配会导致解析异常
递归Mixin必须重写为.loop()模式
Less不支持原生循环，但.loop()配合when守卫能切断调用栈，避免闭包变量持续捕获。
- ❌ 错误写法：
.gen(@n) when (@n > 0) { .gen((@n - 1)); }——仍是递归，深度大时爆栈 - ✅ 正确写法：
.gen(@n) { .loop(@i) when (@i > 0) { /* 样式 */ .loop((@i - 1)); } .loop(@n); }——Less 4.0+能识别此类尾调用优化 - 避免在循环体里调用
unit()、percentage()等计算函数，它们加重AST求值负担 - 生成固定范围（如1–12列）时，直接手写
.col-1 { }….col-12 { }最安全，零风险
@import链必须拆解并启用懒加载
一次性@import "components/**/*.less"会触发AST节点爆炸，尤其当存在环状依赖（A→B→C→A）时，解析器无限循环。
立即学习“前端免费学习笔记（深入）”；
- 用
@import (reference) "mixins.less"——只解析不输出CSS，适合纯工具类 - 用
@import (inline) "reset.css"——跳过Less解析，原样插入文本，省开销 - 非核心样式（主题色、动画）改为按需
@import，不要全量塞进入口文件 - 禁用通配导入：
@import "components/*.less"路径无法静态判定，(once)失效，极易重复载入
嵌套选择器必须压平，不能靠“看起来简洁”
深层嵌套如.a { .b { .c { .d { ... } } }每层都新建独立AST节点，20层≈百万级节点；这不是语法糖，是内存炸弹。
- 超过15层嵌套就该警惕，优先用BEM命名扁平化：
.card-header-title替代.card .header .title - 动态拼接选择器（如
@selector: ~".item-@{i}"; @{selector} { }）会为每个值新建完整分支，禁用 - 检查是否有
&:hover或&:before嵌套在多层&内，旧版Less（ - Ant Design类项目出问题，先看
node_modules/antd/dist/antd.less是否被反复@import，它本身含大量extend和嵌套
真正棘手的是嵌套 + 递归 + 动态变量三者混合的场景——此时堆快照里tree.Node实例常超10万+，单靠配置无法根治，必须从第一行Less代码开始砍冗余逻辑。
