less递归mixin需设明确终止条件（如计数器递减+when guard），避免无限展开；超20层易爆栈，应优先用js插件或预生成；传参须防变量覆盖，拼接选择器用@{var}；非必要场景（如简单重复、响应式嵌套）不应强行递归。
Less递归mixin怎么写才不会爆栈
Less本身不支持真正的循环，递归mixin是唯一能模拟“循环”的方式，但写错会直接触发编译器栈溢出（Maximum call stack size exceeded）。关键不是“能不能递”，而是“什么时候停”。
- 必须定义明确的终止条件，通常靠计数器参数递减 +
whenguard 判断，比如(@i > 0) - 不能把递归调用写在 guard 外面——Less会无条件展开所有分支，导致无限递归
- 计数器建议用整数，避免浮点运算误差导致终止失效
正确写法示例（生成 1–5 级标题字号）：
.gen-font-size(@i: 5) when (@i > 0) {
h@{i} { font-size: (1.2em * @i); }
.gen-font-size((@i - 1));
}为什么嵌套层级深时递归mixin会编译失败
Less编译器对递归深度有硬限制（默认约 128 层），但实际触发爆栈往往远早于此——因为每次递归都生成新选择器、新规则块，AST 节点指数级膨胀。尤其当 mixin 内含嵌套规则或变量计算时，开销更大。
- 真实项目中，超过 20 层递归就该警惕；超过 50 层基本无法稳定编译
- Webpack 的
less-loader可能静默截断，只输出部分 CSS，且不报错 - 若需大量层级（如网格系统列数生成），优先考虑用 JS 插件或构建时脚本预生成，而非运行时递归
Recursive mixin里怎么安全传参和拼接选择器
递归过程中动态拼接类名或属性值，最容易出错的是字符串插值时机和作用域污染。Less 的 @ 变量在 mixin 调用时才求值，但递归调用链中若复用同名变量，后一次会覆盖前一次。
立即学习“前端免费学习笔记（深入）”；
- 所有中间变量必须用唯一命名，或用参数传递（如
.step(@n, @prefix: "")） - 拼接选择器用
@{prefix}-item-@{n}，别用@prefix-item-@n（后者会被当变量名解析） - 避免在递归体里用
@arguments或@@variable动态引用，语义模糊且易失控
错误示例：@name: "col"; .grid(@i) when (@i > 0) { .@{name}@{i} { w: 100%/@i; } .grid((@i - 1)); } —— 这里 @name 是全局变量，递归中不变，但若外部改了它，结果就不可控。
替代方案：什么情况下不该用递归mixin
递归mixin本质是语法糖，不是银弹。当需求涉及条件分支多、层级逻辑耦合强、或需运行时动态控制时，它反而让代码更难维护。
- 需要响应式断点嵌套生成？用
for风格的 loop plugin（如less-plugin-for），比手写递归清晰 - 要根据数据结构生成样式（如主题色数组）？交给构建工具读取 JSON，生成 CSS 文件更可靠
- 只是重复几行规则？直接复制粘贴比加一层递归更安全——少一个执行路径，就少一个崩溃点
真正难的不是写出递归，是判断它是不是当前问题最轻量的解。很多所谓“复杂排版”，拆成几个固定 class 组合，比一套递归生成器更可控。
