不能直接用Less递归mixin生成多级缩进CSS类，因其引发AST爆炸、内存溢出且违背BEM“缩进是表现非语义”原则；应由JS在渲染时主动声明data-level，CSS仅静态声明有限层级规则。
不能直接用 Less 递归 mixin 生成多级缩进 CSS 类——它会导致编译时 AST 爆炸、内存溢出（FATAL ERROR: Ineffective mark-compacts near heap limit），且违背 BEM 原则中“缩进是表现，不是语义”的核心约束。
Less 递归 mixin 生成 .tree-node--level-N 的写法为什么危险
这类写法看似直观：
.gen-levels(@n, @max) when (@n =< @max) {
.tree-node--level-@{n} { padding-left: (@n * 24px); }
.gen-levels((@n + 1), @max);
}
.gen-levels(0, 5);但它在实际项目中极易触发 Less 编译 OOM，尤其当 @max > 8 或嵌套在其他 mixin 内部时。原因很实在：
- 每次递归调用都会新建 AST 节点，5 层就产生至少 15 个节点，20 层就超 200 个，V8 堆内存迅速吃紧
- 生成的类名如
.tree-node--level-3是纯表现类，树深度一变，HTML 和 CSS 就得同步改，维护成本翻倍 - 它把缩进逻辑从数据层（
data-level）挪到了样式层，破坏了 JS 与 CSS 的职责分离
真正可行的缩进方案：JS 注入 data-level + CSS 属性选择器
缩进必须由运行时数据驱动，而不是编译时生成。关键动作在 JS 渲染阶段：
立即学习“前端免费学习笔记（深入）”；
- 递归 walk 函数遍历时，给每个
tree-node元素加上data-level="2"属性 - CSS 只写几行属性选择器，不依赖层级嵌套
- 缩进值用
em或rem更安全，避免像素硬编码
示例 CSS：
.tree-node[data-level="0"] { padding-inline-start: 0; }
.tree-node[data-level="1"] { padding-inline-start: 1.5em; }
.tree-node[data-level="2"] { padding-inline-start: 3em; }
.tree-node[data-level="3"] { padding-inline-start: 4.5em; }注意用 padding-inline-start 而非 padding-left，兼容 RTL 布局；也不依赖 ul ul 这类易被 Flex 干扰的选择器。
如果非要 Less 里处理缩进，只允许扁平化静态展开
Less 不适合动态推导层级，但可以安全地为已知固定深度写展开式规则——前提是深度可控、无递归、无变量参与计算：
- 最大深度明确 ≤ 4，且不会随业务变化
- 所有
data-level值都是字面量（"0"、"1"），不来自@var - 避免任何
@{selector}动态拼接或when (@n > 0)条件递归
正确示例（Less 编译期静态展开）：
.tree-node {
&[data-level="0"] { padding-inline-start: 0; }
&[data-level="1"] { padding-inline-start: 1.5em; }
&[data-level="2"] { padding-inline-start: 3em; }
&[data-level="3"] { padding-inline-start: 4.5em; }
}这种写法不会增加 AST 复杂度，编译快、体积小、可预测。
最常被忽略的一点：缩进不是靠 CSS “猜”出 DOM 深度，而是由 JS 在渲染时**主动声明**当前节点的层级。哪怕树深 100，CSS 也只需加一行规则——真正的可扩展性不在 Less 里，而在数据与 DOM 的对齐上。
