less循环依赖导致构建崩溃的根本原因是编译器线性展开时陷入无限引用链，而非语法错误；应通过postcss-import暴露循环路径、拆解为原子tokens.less、严格分层导入并禁用reference来解决。
Less循环依赖为什么会让构建直接崩溃
不是语法错，而是编译器线性展开时卡死在无限引用链里。Less不建依赖图，@import就是文本拼接+作用域合并，A.less @import B.less，B.less又@import A.less，编译器会反复展开直到内存耗尽，报FATAL ERROR: Allocation failed - JavaScript heap out of memory或静默卡住。
快速定位循环链路的三步法
别靠肉眼翻文件，Less本身不报路径，得借构建工具暴露它：
- 用
postcss-import替代原生@import：Webpack/Vite里配好后，报错会直接打出完整链路，比如A.less → B.less → C.less → A.less - 临时禁用所有
@import (reference)和@import (inline)，让所有导入都实际输出内容——循环会立刻触发Variable @xxx is undefined或Cannot access property，比卡死更易抓 - 在疑似文件顶部加
// @DEBUG: imported by X注释，全局搜索imported by，5分钟内画出依赖图
拆解循环依赖的实操步骤
发现typography.less和spacing.less互引？不能靠@import (multiple)掩盖，必须解耦：
- 新建
core/tokens.less，只放原子变量：@space-xs: 4px;、@font-size-sm: 12px;，不写选择器、不写.mixin()、不@import任何其他文件 - 把
typography.less和spacing.less中互相引用的部分全删掉，改从tokens.less读取 - 确保
tokens.less是项目第一个被@import的文件，比如放在index.less最顶部
为什么@import (reference)救不了循环
@import (reference) "mixins.less";只控制“样式是否输出”，不解决“变量/mixin是否可用”。如果A.less用(reference)导入B.less，又在B.less里调用了A.less定义的.btn()，编译仍报Undefined mixin '.btn'——因为A.less的内容还没进作用域。
真正安全的复用只有两种：抽成独立tokens.less，或把逻辑下沉到JS层（比如用CSS自定义属性+JS计算值）。复杂点在于，循环往往藏在三层以上@import链里，且reference修饰符会让问题更隐蔽。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
