Less的!default仅在编译期生效且须位于首次声明前，不能模拟CSS变量的运行时fallback；正确做法是分层管理变量（vars-base.less + vars-user.less），严格控制@import顺序，并通过CSS变量实现运行时主题切换。
Less变量本身不支持CSS变量那种“运行时默认值”
很多人看到var(--primary-color, #1890ff)就下意识想在Less里写@primary-color: #1890ff !default;来模拟——这容易误解。Less的!default只在**编译期**起作用，且仅当该变量此前完全未被声明过才生效；它不是CSS自定义属性里的 fallback 机制，也不参与浏览器渲染层的计算。
常见错误现象：@primary-color: #007bff !default;写在themes/dark.less里，但项目入口先@import 'base.less';，而base.less里已有@primary-color: #333;——此时!default彻底失效，深色主题根本不会覆盖。
-
!default必须出现在所有可能的首次赋值之前，否则形同虚设 - 不能用
@primary-color: lighten(@primary-color, 10%) !default;——右侧表达式在变量未落定前引用自身，会报Recursive variable definition - Webpack 的
modifyVars配置（如{ '@primary-color': '#52c418' }）会直接注入，绕过!default逻辑，二者需同步维护
真正可落地的“默认值”组织方式：分层 + 显式开关
把“默认值”从!default的语义陷阱里拉出来，改用结构化控制。核心是让开发者一眼看清哪些值是基础、哪些是可选覆盖、哪些是强制生效。
推荐做法：
立即学习“前端免费学习笔记（深入）”；
- 新建
vars-base.less，只放带!default的初始声明：@primary-color: #1890ff !default;、@border-radius: 4px !default; - 新建
vars-user.less（或由构建脚本生成），里面写无!default的直接赋值：@primary-color: #ff6b6b; - 主入口
index.less严格按顺序@import：@import 'vars-base.less'; @import 'vars-user.less'; @import 'components/button.less'; - 避免在组件文件（如
button.less）里重复@import 'vars-base.less'——变量已在顶层注入，重复导入可能触发不可控覆盖
如何让“默认值”真正影响最终CSS输出
光有变量声明没用。Less变量必须穿透到每一条样式声明中，否则换主题就是换空气。
关键检查点：
- 所有颜色、间距、圆角等值，都得来自变量，而不是硬编码：
background: @primary-color;✅，background: #1890ff;❌ - 如果要用
lighten()、fade()等函数，确保它们作用于变量而非字面量：color: lighten(@text-color, 10%);✅ - 若需运行时切换（如深色模式），必须把
@primary-color映射为:root { --primary-color: @primary-color; }，再在样式中用var(--primary-color)——Less变量只管构建期配置，CSS变量才管运行时响应
容易被忽略的细节：@import顺序与作用域污染
Less没有模块作用域，所有@import拼成一个大文件线性解析。顺序错了，变量就锁死了。
典型翻车场景：
- 第三方UI库（如Ant Design Less）的
@import写在你自己的vars.less之前 → 它们用的是默认值，你的覆盖无效 - 多个主题文件（
theme-light.less、theme-dark.less）被同时@import→ 后者覆盖前者，但无法条件加载 - 在
mixin内部重新声明@primary-color→ 这个变量只在mixin作用域内有效，对外不可见，也无法被外部覆盖
最稳妥的做法：只保留一个主题入口文件，通过构建参数（如Webpack modifyVars 或 Vite css.preprocessorOptions.less.additionalData）注入变量，避免手动@import多套主题文件带来的顺序风险。
