<p>Less编译卡死或报FATAL ERROR: Allocation failed - JavaScript heap out of memory，根本原因是@import链形成隐式闭环（如A→B→C→A），导致编译器线性展开时反复拼接文本直至堆内存耗尽；它不报循环依赖，只静默卡住或崩溃，需通过改@import为(inline)、用postcss-import、加@DEBUG注释或拆解为原子tokens.less等方法定位并打破闭环。</p>
Less无限递归编译卡死或报FATAL ERROR: Allocation failed - JavaScript heap out of memory
这不是内存不够，而是@import链形成了隐式闭环，比如A.less → B.less → C.less → A.less，Less编译器线性展开时反复拼接文本，直到V8堆内存耗尽。它不会报“循环依赖”，只会静默卡住或崩溃。
快速暴露路径的方法：
- 把项目里所有
@import临时改成@import (inline)——循环会立刻触发Variable @xxx is undefined或Cannot access property，错误位置就是断点 - 在Webpack/Vite中用
postcss-import替代原生@import，报错时直接打出完整引用链：A.less → B.less → C.less → A.less - 在疑似文件顶部加
// @DEBUG: imported by X，全局搜索imported by，5分钟内画出依赖图
拆解typography.less和spacing.less互引这类典型循环
别用@import (multiple)或@import (reference)掩盖问题——它们不解决作用域加载顺序，只控制输出行为。真正解耦必须物理隔离变量来源。
实操步骤：
立即学习“前端免费学习笔记（深入）”；
- 新建
core/tokens.less，只放原子级定义：@space-xs: 4px;、@font-size-sm: 12px;，禁止含任何选择器、mixin或@import - 删掉
typography.less和spacing.less里互相引用的变量，全部改写成@import "core/tokens.less";再读取 - 确保
tokens.less是项目第一个被@import的文件（如index.less最顶部） -
tokens.less自身严禁@import任何其他.less文件——它是依赖树唯一的根
为什么@import (reference)救不了循环
它只决定“样式是否输出”，不影响“变量/mixin是否进入当前作用域”。比如A.less用@import (reference) "B.less";，又在B.less里调用A.less定义的.btn()，编译仍报Undefined mixin '.btn'——因为A.less的内容还没解析到作用域里。
安全复用只有两种方式：
- 抽成独立
tokens.less，靠导入顺序保证变量先就位 - 把逻辑下沉到JS层，比如用CSS自定义属性+JS计算值，彻底绕开Less作用域模型
复杂点在于循环常藏在三层以上@import链里
比如button.less→theme.less→mixins.less→button.less，肉眼很难发现。更麻烦的是@import (reference)会让问题更隐蔽：它让文件“看似没参与编译”，实则变量仍在作用域里乱窜。一旦某处漏掉括号或拼错变量名，错误会延迟到下游文件才爆发，定位成本翻倍。
