Less变量作用域决定主题切换有效性：仅顶层变量可被@import或modifyVars覆盖；变量须统一声明于独立文件并全程引用，避免硬编码；CSS自定义属性支持运行时换肤，Less变量仅构建时生效。
Less变量作用域如何影响主题切换
Less的主题切换本质是变量值的重新注入，不是CSS类名切换。关键在于变量是否被定义在可覆盖的作用域里——顶层变量（非嵌套块内）才能被后续@import或modifyVars覆盖。
常见错误现象：@primary-color: #1890ff;写在某个.btn {}规则内部，之后怎么重定义都无效；或者多个@import顺序颠倒，后导入的变量被先导入的“锁死”。
实操建议：
- 所有主题变量统一放在单独文件（如
variables.less），且仅包含@xxx:声明，不带任何选择器 - 主样式文件用
@import 'variables.less';开头，确保变量在使用前已声明 - 避免在
mixin或:extend()中直接硬编码颜色值，否则无法被变量机制接管
运行时动态换肤：Webpack + less-loader 的 modifyVars 怎么配
开发期热更新主题靠less-loader的modifyVars选项，它会在每次编译时把传入的对象合并进Less全局作用域，优先级高于原文件中的默认值。
立即学习“前端免费学习笔记（深入）”；
容易踩的坑：modifyVars只在构建时生效，不能用于浏览器里实时切换；传入的键名必须和Less源码中变量名**完全一致**（包括@符号），少写一个@就失效。
实操建议：
- Webpack配置中写成
modifyVars: { '@primary-color': '#52c418', '@border-radius-base': '4px' } - 变量名区分大小写，
@TextColor≠@text-color - 如果变量值含单位或函数（如
fade(@primary-color, 80%)），确保modifyVars里也传字符串形式：'fade(#52c418, 80%)'
如何让主题变量真正“可替换”，而不是写死在样式里
很多团队写了@primary-color，但按钮背景仍写background: #1890ff;，等于白搭。变量必须贯穿到最终CSS声明中，否则换主题毫无意义。
性能与兼容性影响：过度嵌套lighten(@primary-color, 10%)等函数会增加编译耗时，但对最终CSS无 runtime 开销；注意color相关函数在Less 3.x+才支持HSLA参数，旧版本会报错error evaluating function `hsla`。
实操建议：
- 所有颜色、间距、圆角、阴影值，全部来自变量，禁用字面量数字/颜色值
- 用
.theme-dark { ... }这类class包裹整套深色规则时，不要重复定义变量，而是用& when (@theme = dark)条件混入 - 避免在
@media查询里重复写@primary-color，应提前计算好响应式变量（如@font-size-sm），再统一使用
为什么CSS自定义属性（CSS Variables）比Less变量更适合线上换肤
Less变量在构建时就编译成静态值，换肤必须重新打包；而css-vars可在运行时通过document.documentElement.style.setProperty('--primary-color', '#52c418')即时生效，无需刷新。
但混合使用时容易混乱：Less里引用@primary-color，又在JS里改--primary-color，两者互不影响。真正要动态，就得把Less变量“转译”为CSS变量，比如：@primary-color: var(--primary-color, #1890ff);。
实操建议：
- 新项目直接用CSS变量做主题，Less只负责结构和逻辑，不承担主题值存储
- 老Less项目迁移时，在
variables.less末尾加一层代理：@primary-color: var(--primary-color, #1890ff);，保持原有调用方式不变 - 注意CSS变量不支持Less的函数运算，
lighten(var(--primary-color), 10%)会报错，得用color-mix()或JS预计算
主题切换真正的复杂点不在语法，而在变量粒度设计——@btn-bg和@primary-color该不该解耦？深色模式下@text-color要不要随@bg-color联动？这些决策一旦定下，改起来比换一行代码难得多。
