less 的 map 并不比普通变量更好用，仅在键名固定且需批量生成原子类时有优势，但受限于编译期不可变、无合并机制、语法严格及版本要求。
Less 的 map 特性在结构化数据管理上**并不比普通变量“更好用”**——它只是在特定场景下提供了更明确的语义和批量操作能力，但代价是版本限制、语法约束和编译期不可变性。盲目用 map 反而容易踩坑。
Less 3.1+ 的 map 是静态编译期结构，不是运行时对象
你写 @colors: (primary: #007bff, success: #28a745)，这个 @colors 不是 JavaScript 里的 Map，不能 .set()、.has() 或遍历键名。它只是一段编译器能识别的字面量结构，仅支持 map-get() 和配合 .each()（需先转 list）。常见错误：
- 直接
.each(@colors) { ... }→ 报错Cannot call method 'each' on null，因为.each()不接受map类型参数 - 在
.each()回调里把参数当键名用：@key: @value→ 实际传入的是整个键值对（类型为map），拼 class 名会失败 - 想用变量作键：
map-get(@colors, @key)→ 编译期无法解析，报Undefined variable
什么时候真该用 map 而不是变量前缀？
只有当你需要**批量生成原子类或条件查表且键名固定**时，map 才比 @btn-size-xs 这类前缀变量有优势。比如设计系统中统一导出颜色类：
@colors: (primary: #007bff, success: #28a745, warning: #ffc107);
@keys: map-keys(@colors);
@vals: map-values(@colors);
.each(@keys) {
@i: index(@keys, @value);
@key: extract(@keys, @i);
@val: extract(@vals, @i);
.text-@{key} { color: @val; }
.bg-@{key} { background-color: @val; }
}
这种写法比手写三份 .text-primary 更可维护，但前提是：
- 确认
lessc --version≥ 3.1.0（3.0.x 有.each()bug） -
@colors必须是顶层变量，不能嵌套在另一个 map 里 - 键名只能是标识符（如
primary），不能含空格或连字符
嵌套主题配置必须分层调用 map-get
设计系统常把颜色、间距按主题组织：@theme: (light: (colors: (primary: #007bff), spacing: (sm: 4px)))。这时你不能写 map-get(@theme, light.colors.primary) —— Less 不支持路径式访问。
必须拆成两步：
@light-theme: map-get(@theme, light); @light-colors: map-get(@light-theme, colors); @primary: map-get(@light-colors, primary);
这种写法比变量前缀更清晰（@light-colors-primary 易混淆作用域），但也更冗长。一旦层级加深，维护成本反而上升。
真正容易被忽略的点：map 在 Less 里没有“合并”或“覆盖”机制，map-merge() 是 Sass 的函数，Less 原生不提供。你要实现深合并，得靠插件或手动展开，这会让构建流程变得脆弱。所以多数项目用变量前缀 + mixin 封装，反而是更稳的选择。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
