less多皮肤预生成的核心机制是构建时通过不同入口文件（如theme-dark.less、theme-light.less）预先定义覆盖变量，并在导入公共样式前完成赋值，利用变量作用域“就近+顺序”规则实现主题分离编译。
Less 多皮肤预生成的核心机制是什么
Less 本身不支持运行时换肤，多皮肤必须靠构建时预编译实现。关键在于：用同一套组件样式代码，通过不同入口文件（如 theme-dark.less、theme-light.less）导入相同的 components.less，但各自先定义一组覆盖变量（如 @primary-color），从而产出独立 CSS 文件。
多个入口文件怎么组织才不重复又易维护
入口文件只做三件事：重置变量、导入公共样式、导出最终 CSS。不能把组件样式逻辑写进入口里，否则维护成本爆炸。
-
themes/dark.less：只包含@primary-color: #1890ff;、@bg-color: #1f1f1f;等覆盖声明，末尾@import "../src/index.less"; -
themes/light.less：同理，变量值不同，其余结构完全一致 -
src/index.less是唯一业务样式入口，里面所有颜色/间距都基于@primary-color等变量计算，不写死值 - 构建脚本（如
lessc themes/dark.less dist/dark.css）需为每个入口单独调用，不能合并编译
变量覆盖为什么有时不生效
Less 变量作用域是“就近+顺序”，不是“后声明覆盖前声明”。如果在 components.less 里提前用了 @primary-color，而你的入口文件在 @import components.less 之后才定义它，那变量根本没被读到。
- 确保所有变量定义语句出现在任何
@import公共样式之前 - 避免在
src/下的任意文件里用@primary-color: ...赋值——这会锁死值，失去覆盖能力 - 慎用
!default：只在基础变量文件（如variables.less）中用@primary-color: #1890ff !default;，入口文件直接赋值即可覆盖 - 检查是否误用了
@import (reference)：它会跳过变量声明，导致覆盖失效
构建时如何避免 CSS 体积膨胀
每套皮肤单独编译，CSS 内容几乎完全重复，只是变量值不同。单纯输出多份 CSS 会造成大量冗余。
- 启用
lessc --clean-css或后续走 PostCSS 的cssnano，能删掉注释、合并重复规则（但无法跨文件去重） - 更彻底的做法：把公共样式抽成
common.css（不含变量值的结构类），再用 JS 动态注入主题色 CSS 变量 ——但这已脱离 Less 预生成范畴 - 真正可控的压缩点在变量粒度：不要为每个组件定义独立颜色变量（如
@button-bg、@card-bg），统一用@bg-primary、@bg-secondary，减少可变点数量
变量层级越浅、覆盖点越少，预生成的 CSS 差异越小，也越容易后期做增量更新。很多人卡在“以为改一个变量就能换全站皮肤”，结果发现按钮圆角、阴影强度、字体粗细全是独立变量，最后要维护二十多个入口文件——这不是 Less 的问题，是变量抽象没做好。
