Less变量文件应统一定义在variables.less中，仅保留@primary-color等语义化顶层变量，组件样式须引用而非硬编码颜色，配合构建工具监听变量变更实现主题切换。
Less变量文件怎么组织才方便换主题色
主题色切换本质是把所有颜色值从硬编码抽成变量，再集中管理。关键不是“用了Less”，而是变量分层是否合理——顶层只留@primary-color、@text-color这类语义化变量，底层组件样式（比如.btn、.header）只能引用这些顶层变量，不能直接写#4a90e2。
常见错误：在button.less里直接写background: @primary-color，但@primary-color又定义在theme-blue.less里，导致换色时要改多个文件。正确做法是建一个variables.less，所有主题色变量都定义在这里，其他文件统一@import "variables"。
- 变量命名用语义，不用物理色值，比如用
@brand-primary而非@blue-500 - 避免在变量里嵌套计算，如
@primary-dark: darken(@primary-color, 10%)——编译时固定，换色后不会联动更新 - 深色模式支持？加一层
@mode开关不如拆两套变量文件（light-vars.less/dark-vars.less），按需导入更可控
如何让一个变量改动实时影响所有组件
Less本身不支持运行时换肤，所谓“实时”指重新编译CSS。真正起作用的是构建流程——Webpack的less-loader或Gulp的less插件必须配置为监听variables.less变更并触发重编译。否则改了变量，页面刷新也看不到效果。
典型错误现象：npm run dev下修改@primary-color，浏览器没变化。大概率是less-loader没配modifyVars，或者变量文件路径没被正确@import进入口main.less。
立即学习“前端免费学习笔记（深入）”；
- Webpack中用
less-loader时，modifyVars参数只对全局变量生效，局部@import的变量文件需确保路径正确且无拼写错误 - 变量文件里别用
@import嵌套太多层，Less解析顺序可能导致覆盖失效（后@import的同名变量会覆盖前面的） - 检查浏览器开发者工具里生成的CSS，搜索
primary-color对应的实际值，确认是不是你刚改的那个
为什么改了变量，部分按钮颜色却没变
不是变量没生效，是某些样式绕过了变量体系。最常见两类：一是内联style属性（比如div style="color: #333"），二是第三方UI库的CSS（如Ant Design默认用CSS-in-JS或独立CSS文件，不读你的Less变量）。
另一个隐蔽原因：CSS优先级。比如某个组件写了.btn { color: @text-color; }，但另一处写了.btn.active { color: #ff6b6b !important; }，后者直接写死颜色+!important，变量再改也没用。
- 全局搜索项目里所有
rgb(、hsl(、#开头的颜色字面量，替换成对应变量 - 第三方组件主题尽量走官方API（如Ant Design的
ConfigProvider），别试图用Less覆盖其内部类 - 用浏览器“Computed”面板查目标元素的真实
color来源，定位到具体哪条CSS规则在起作用
多主题打包时，怎么避免CSS体积暴增
一个主题一套CSS文件是安全做法，但容易重复打包公共样式（比如排版、栅格）。更优解是提取“不变部分”为base.css，“可变部分”单独编译为theme-light.css和theme-dark.css，通过<link rel="stylesheet">动态加载。
如果强行用同一份CSS + JS切换class（如body.theme-dark），Less变量编译后就固化了，JS无法改变已生成的CSS规则——这时候得用CSS自定义属性（--primary-color），Less只负责生成初始值，后续靠JS改:root。
- Less变量方案适合构建时确定主题；运行时换肤必须配合CSS Custom Properties
- 不要在Less里用
@media (prefers-color-scheme: dark)自动切主题——它只响应系统设置，不响应用户手动切换 - 检查最终打包产物，确认不同主题CSS文件之间重复率低于15%，否则变量分层可能出问题
变量不是魔法，它只解决“一处改、处处变”的前提，但前提是所有颜色都经过它，且构建链路真能感知到它的变化。漏掉任何一个环节，主题色就卡在某个按钮上不动了。
