less递归mixin卡死或爆内存的主因是解析器无终止条件致ast节点指数膨胀，v8堆内存耗尽；典型伪递归如.gen(@n) when (@n > 0) { .gen((@n - 1)); } 必须加显式上限与校验。
Less递归mixin为什么一跑就卡死或爆内存
根本不是代码写错了，而是Less解析器在展开时没终止条件，AST节点数指数级膨胀，V8堆内存瞬间打满。报FATAL ERROR: JavaScript heap out of memory时，90%以上是递归失控，不是机器内存小。
.gen(@n) when (@n > 0) { .gen((@n - 1)); } 这种写法必须改
这是最典型的“伪递归”陷阱：每次调用都新建一层作用域和完整AST节点，且不释放；@n若来自未校验变量（比如@n: @count + 1;），连最大深度都不可控。
- 必须加显式上限：
.gen(@n) when (@n > 0) and (@n = - 更推荐改用
.loop()尾调用模式（Less 4.0+支持），它能复用栈帧，避免深度嵌套 - 调试时临时注释所有
.mixin()定义，如果仍OOM，说明问题出在嵌套层级或@import链，而非递归本身
动态拼接选择器 + 递归 = 节点爆炸
像@selector: ~".item-@{i}"; @{selector} { .gen((@i + 1)); }这种写法，每轮递归都生成一个全新选择器分支，AST节点数不是线性增长，而是O(n²)甚至更高。
- 禁止在递归体里用
~"..."插值生成选择器 - 把循环逻辑抽到JS层（如用PostCSS插件生成），或改用
@keyframes动画那种受控插值场景 - 用
//注释掉不用的递归分支比用when条件更彻底——注释不参与AST构建
真正难搞的是“递归+嵌套+动态变量”混合场景
比如在一个.card { .header { .title { .gen(@level); } } }里调用递归mixin，又让@level从@import进来的变量计算得来——此时AST深度 × 分支数 × 变量作用域覆盖，很容易突破百万节点。
- 先砍掉所有无上限
when条件，再压平嵌套（.card-header-title代替三层嵌套） -
@import链必须单向：禁止A.less → B.less → A.less，用postcss-import暴露链路比手动搜快得多 - tokens.less必须是根文件，禁止它再
@import任何其他文件——这是唯一能稳住作用域边界的办法
递归本身没问题，问题永远出在“没有明确退出边界”和“在错误位置触发节点分裂”。Less不提供运行时栈深限制，所以重构比调--max-old-space-size实在得多。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
