在 Less 中批量生成图标坐标时，许多开发者容易遇到一个常见的“陷阱”：尝试使用 .each() 循环，却发现变量 @key 总是返回 undefined。这其实源于对 Less 语法的一个常见误解。
Less 中 .each() 循环生成图标坐标时，为何 @key 总是 undefined？
根本原因在于，.each() 并非 Less 语言的原生特性。它是 PostCSS 或某些特定插件（例如 less-plugin-lists）提供的扩展语法。如果在纯 Less 环境中直接编写 .each(@icons, ...) { ... }，编译器会直接报错：Unrecognised input。
那么，在 Less 里正确的迭代方式是什么？主要有两条路径：一是使用 .for() 循环（需要引入 less-plugin-for 插件），二是采用纯 Less 的递归混合宏。后者是更通用、更推荐的做法，因为它不依赖额外构建插件，兼容所有标准 Less 编译器，无论是 VS Code 的插件、Webpack 的 less-loader，还是其他构建工具，都能顺畅运行。
具体来说，标准 Less 路径如下：
- 首先，将图标数据组织成一个空格分隔的列表，例如：
@icons: "home" 0 0, "search" -16px -24px, "user" -32px -48px; - 然后，编写一个递归的
.generate-icons()混合宏来处理这个列表。宏的逻辑是：每次递归取出列表的第一项，处理完毕后，将剩余项传递给自身继续处理，直到列表为空。 - 这里有个细节需要注意：Less 的
extract()函数索引是从 1 开始的，所以extract(@list, 1)才是获取首项的正确方式。
如何使用 Less 递归混合宏批量生成 background-position 规则？
这个方案的核心，在于将坐标数据“摊平”成一种可迭代的结构，并在每次递归中动态拼接出对应的 CSS 类名和定位值。关键在于如何清晰地分离图标名称和其对应的 X、Y 坐标，并且要确保坐标值可以携带单位（比如 -16px）。
.generate-icons(@list) when (length(@list) > 0) {
@item: extract(@list, 1);
@name: extract(@item, 1);
@x: extract(@item, 2);
@y: extract(@item, 3);
.icon-@{name} {
background-position: @x @y;
}
// 递归处理剩余项
.generate-icons(extract(@list, 2..length(@list)));
}
.generate-icons(@list) when (length(@list) = 0) {}
// 调用
@icons: "home" 0 0,
"search" -16px -24px,
"user" -32px -48px;
.generate-icons(@icons);
经过编译，上述代码会输出：.icon-home { background-position: 0 0; }、.icon-search { background-position: -16px -24px; } 等一系列规则。这里需要留意一个语法点：extract(@list, 2..length(@list)) 这种切片写法是 Less 4.0 及以上版本才支持的。如果你的项目使用的是旧版本，可能需要通过 set-nth() 等函数来模拟实现列表的切片操作。
为什么生成的 background-position 值没单位就失效？
这涉及到 Less 中数值的默认处理方式。在 Less 里，像 0、-16 这样的数字字面量，默认被视为无单位的纯数值。然而，CSS 的 background-position 属性对单位有明确要求，它期望的是像 px、rem 这样的长度单位。如果坐标值没有单位，浏览器可能会忽略这条声明，或者产生非预期的解析结果。
举个例子，直接写 "home" 0 0，编译后是 background-position: 0 0，这在 CSS 里是合法的（0 本身可以作为有效的长度值）。但如果是 "search" -16 -24，编译后就成了 background-position: -16 -24。此时，浏览器很可能会将 -16 和 -24 解析为类似 left、top 这样的关键字，而不是你期望的像素偏移量。
如何避免这个问题？
- 最直接的方法：在定义坐标数据时，就为每个值显式地加上单位，例如
"search" -16px -24px。 - 如果坐标数据来源于 JSON 或外部配置，无法预先加单位，那么可以在 Less 内部使用
unit()函数来补充，比如unit(extract(@item, 2), px)。 - 尽量避免使用
~"-16px"这种字符串拼接的方式来绕过类型检查。虽然它可能暂时生效，但会使得这个值无法参与后续的 Less 计算（比如你想对图标进行整体缩放时就会遇到麻烦）。
生成的 CSS 类名带特殊字符（如 / 或 .）怎么处理？
另一个常见的问题是图标名称本身可能包含特殊字符。比如，一个图标文件可能被命名为 arrow/left.svg，对应的名称就是 "arrow/left"。当 Less 尝试将 @{name} 插值到类名中，生成 .icon-arrow/left 时，这个斜杠 / 会导致编译失败，或者产生一个非法的 CSS 选择器。同样的问题也适用于点号 . 或空格。
指望 CSS 选择器自动转义是不现实的。更安全的做法是在数据层面就进行预处理，对名称进行标准化清洗。一个典型的清洗函数可能是这样的：
.clean-name(@str) {
@n1: replace(@str, "/", "-");
@n2: replace(@n1, "\.", "");
@n3: replace(@n2, " ", "-");
@n3;
}
// 使用时
@name-clean: .clean-name(extract(@item, 1));
.icon-@{name-clean} { ... }
这个函数会将斜杠替换为连字符，删除点号，并将空格转为连字符。当然，还有更彻底的方案，比如放弃语义化的类名，改用编号（.icon-1、.icon-2），然后通过 data-icon 属性或 :nth-child() 选择器来控制显示哪个图标。但这通常背离了我们使用语义化类名的初衷。
话说回来，最可靠的方法其实是在项目规范层面进行约束：规定图标文件名只允许使用小写字母、数字和连字符（即 [a-z0-9-] 字符集）。从源头控制，远比在运行时进行复杂的清洗要简单和稳定。
总结一下，要让 Less 递归宏稳定地批量生成图标 CSS，有三个关键点必须牢牢抓住：递归终止条件的正确设置、坐标值的单位显式声明，以及图标名称的预处理清洗。这三个环节中任何一个被忽略，都可能导致生成的 CSS 在特定场景下静默失效，给调试带来不小的麻烦。
