典型诱因是深层嵌套选择器、过度@import链及递归.mixin()滥用，导致ast构建和变量求值内存持续累积；应禁用递归mixin，改用.loop()配合when守卫和计数器模拟循环以切断调用栈。
Less编译时触发OutOfMemoryError的典型诱因
这不是Node.js内存配置不够那么简单——当Less文件中存在深层嵌套选择器、过度展开的@import链，或滥用递归.mixin()（尤其带参数计算的），编译器会在AST构建和变量求值阶段持续累积内存引用，最终在V8堆空间耗尽时抛出FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory。
禁用递归Mixin并改用循环展开（Less 4.0+）
Less本身不支持原生for循环，但可通过.loop()模式配合when守卫和计数器变量模拟。关键是要**切断递归调用栈**，避免每次调用都压入新执行上下文：
.generate-grids(@n, @i: 1) when (@i =.generate-grids(@n) {
.loop(@i) when (@i > 0) {
.grid-@{i} { width: (@i * 12px); }
.loop((@i - 1));
}
.loop(@n);
}
// ✅ 改写为尾调用优化友好形式（Less 4.0+解析器能识别部分尾递归）
- 优先用
.loop(@n)代替.mixin(@n, @i)，减少闭包捕获变量数量 - 若目标是生成固定范围（如1–12列），直接写死展开更安全：
.grid-1 { ... } .grid-2 { ... } - 避免在递归体中调用
unit()、percentage()等计算密集函数
拆分@import与启用懒加载（Less 3.10+）
大型项目常因@import "components/**"一次性载入数十个文件，导致AST节点爆炸。Less 3.10起支持reference和inline导入模式：
- 用
@import (reference) "mixins.less";—— 只解析不输出CSS，适合纯工具类 - 用
@import (inline) "reset.css";—— 原样插入文本，跳过Less解析开销 - 将非核心样式（如主题色、动画）改为按需
@import，而非在入口文件全量引入 - 检查是否有
@import形成环状依赖（A→B→C→A），这会导致无限解析
调整Node.js内存限制与Less编译选项
临时缓解需直击V8堆内存瓶颈，但必须配合代码层优化，否则只是延缓报错：
- 启动Less CLI时显式扩容：
node --max-old-space-size=4096 node_modules/less/bin/lessc src/main.less - 在Webpack中配置
less-loader时传参：{ options: { math: 'always', javascriptEnabled: false } }—— 关闭JS表达式可大幅降低AST复杂度 - 禁用
javascriptEnabled（默认false），防止意外执行~`js code`导致内存泄漏 - 慎用
math: 'strict'，它会强制所有运算提前求值，可能在编译期触发大量中间变量分配
真正棘手的是那些隐藏在.less文件里的隐式循环——比如一个@each遍历200项颜色变量，每项又触发3层嵌套选择器生成。这种场景下，光调大内存无济于事，必须回到样式结构本身做减法。
