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() 遍历并结合属性插值生成 :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 会报错；路径必须用方括号。
立即学习“前端免费学习笔记（深入）”；
.theme-mixin() 封装的核心是避免重复写 var(--*)
业务组件不应裸写 color: var(--text-color)，否则后期要加 fallback、加 transition 或改命名时得全局搜。统一用 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 内部加降级逻辑（例如先写
background-color: #1890ff，再覆盖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 参数。
