Less运行时主题切换需通过@themes Map+each()生成CSS变量并用.theme-mixin()封装调用，避免多文件维护、变量覆盖及条件分支不可靠问题，构建工具须监听themes.less变更。
开门见山地说，Less本身并不支持真正的运行时主题切换。我们常说的“优雅换肤”，其本质是一套组合拳：在编译期完成变量注入，再通过CSS自定义属性（也就是那些--*变量）作为桥梁，将颜色值传递到运行时。这套方案的核心骨架，离不开@themes这个Map结构，以及一个封装良好的.theme-mixin()来驱动逻辑复用。
为什么不能直接用多套 variables.less 文件切换
乍一看，手动维护light-vars.less、dark-vars.less等独立文件似乎很直观。但实践起来，这几乎是给自己挖坑，三个硬伤非常明显：
- 每次新增主题，都意味着要复制粘贴整套变量，稍不留神就会漏改，或者出现命名上的细微差异，为后续维护埋下隐患。
@import的顺序一旦错位，同名变量就会被静默覆盖。Less编译器通常不会为此报错，最终生效的总是后一个，排查起来相当头疼。- 你无法在同一个样式块里根据主题做条件判断。比如想写
.btn { color: if(@theme == dark, #fff, #333); }，这种写法在旧版Less中并不可靠，更重要的是，它完全背离了变量集中管理的初衷，让逻辑变得分散。
@themes Map 定义必须配合 each() 和嵌套选择器生成 CSS 变量
Map是Less 4.0及以上版本支持的原生数据结构，但它不能直接用于CSS声明。正确的做法是：用each()函数遍历Map，并结合属性插值，动态生成挂载在:root[data-theme="xxx"]这类选择器下的--*变量。来看一个标准示例：
@themes: {
light: {
primary-color: #1890ff;
bg-color: #ffffff;
text-color: #333333;
};
dark: {
primary-color: #177ddc;
bg-color: #141414;
text-color: #f0f0f0;
};
};
each(@themes, {
@theme-name: @key;
@theme-vars: @value;
:root[data-theme="@{theme-name}"] {
--primary-color: @theme-vars[primary-color];
--bg-color: @theme-vars[bg-color];
--text-color: @theme-vars[text-color];
}
});
这里有个细节需要特别注意：取值时，必须使用@theme-vars[primary-color]这样的方括号语法。如果写成@theme-vars.primary-color，Less编译器会直接报错。
立即学习“前端免费学习笔记（深入）”；
.theme-mixin() 封装的核心是避免重复写 var(--*)
在业务组件的样式里，如果到处直接写color: var(--text-color)，后期维护就会变成一场噩梦。想加个回退值（fallback）、统一添加过渡动画，或者仅仅是修改变量名，都不得不进行全局搜索替换。解决之道，就是用一个mixin统一封装一层。这不仅能收敛所有调用点，也为未来的扩展预留了空间：
.theme-mixin(@property, @var-name) {
@{property}: var(--@{var-name});
}
// 使用
.button {
.theme-mixin(background-color, primary-color);
.theme-mixin(color, text-color);
transition: background-color 0.2s;
}
- 这样做的好处立竿见影：假如某天你需要对深色模式下的
primary-color进行lighten()微调，只需在Map里修改对应的值，所有用到这个颜色的组件都会自动更新，无需逐一修改。 - 如果需要兼容不支持CSS变量的旧浏览器，可以在这个mixin内部轻松加入降级逻辑，比如先写一行固定的色值，再用
var()声明覆盖。 - 另外提醒一点：
@property参数不要写成字符串形式（如"background-color"），Less会将其视为字面量，导致编译失败。
构建流程必须监听 themes.less 并重编译，否则改了没反应
这是最容易让人卡住的环节：明明修改了@themes里的颜色值，刷新页面却发现纹丝不动。问题往往不出在代码逻辑，而是构建工具没有感知到文件变更：
- 对于Webpack用户，务必检查
less-loader的配置，确认是否通过modifyVars正确注入了变量，或者主题文件是否被正确@import到了入口的main.less中。 - 使用Gulp的开发者，则需要检查
gulp-less插件的paths选项是否包含了themes.less文件所在的目录，否则watch任务可能不会触发。 - 如果你依赖VS Code插件（如“Easy LESS”）进行实时编译，要知道它默认可能不会监听被嵌套引入（@import）的子文件变更。这时，还是得依靠命令行或项目自身的构建工具来保证编译。
说到底，衡量一套换肤方案是否真正“优雅”，关键不在于语法有多么炫酷，而在于开发者修改变量后，从保存文件到在浏览器中看到效果，中间是否需要额外的人工干预步骤。很多时候，差的就是那一行正确的watch配置，或一个被忽略的modifyVars参数。
