一个常见的误区：很多人把 !default 当作 CSS 变量 var(--color, #1890ff) 的 Less 替代版，结果在配置深色主题时屡屡碰壁。修改了数值却发现效果未变——这并非代码错误，而是变量从未进入预期路径。
不少人困惑于为什么 !default 在 Less 中表现如此“特殊”。实际上，它并非 CSS 变量那样的运行时回退机制，而是在编译期发挥作用，且只认第一次赋值。一旦前面某处已经落定了 @primary-color: #333;，后续再写多少次 @primary-color: #ff6b6b !default; 都无济于事，编译器甚至不会给出任何告警。
举个例子：你在 themes/dark.less 中编写了 @primary-color: #ff6b6b !default;，但入口文件先导入了 base.less，而 base.less 恰好有 @primary-color: #333;。结果就是 !default 被直接跳过，深色主题根本无法覆盖。关键在于顺序——谁先定义谁生效。
需要留意以下几个极易踩坑的地方：
!default必须出现在所有可能的首次赋值之前。顺序一旦出错，等同于无效。- 避免写出
@spacing: @spacing * 2 !default;这类代码，右侧引用的变量若尚未落定，编译器会直接报Recursive variable definition错误。 - Webpack 的
modifyVars注入（例如{ '@primary-color': '#52c418' }）是字符串级别的替换，直接绕过了!default的判断逻辑。若同时使用两套配置，必须手动同步，否则必然出现冲突。
变量覆盖失败的三个典型场景
你以为在 dark.less 中声明就能生效？实际操作中，让你落空的往往是下面这些情况。
- 在组件文件中重复导入变量文件。比如
button.less里又@import 'variables.less'，导入顺序一旦混乱，同一变量被多次声明，!default只对首次有效。 - 将
!default塞入.mixin中。Mixin 作用域内的变量解析不稳定，很容易被遗漏或误覆盖。 - 用空声明“占位”。这很隐蔽：
@color: ;本身已构成一次声明，后续无论写多少次@color: red !default;，都会被忽略。
真正能落地的默认值管理方式
我的建议是，别与 !default 死磕。它只适合做“基础库兜底”，不适合充当“主题开关”。若想稳定控制变量覆盖，可以尝试以下方案。
- 新建一个
vars-base.less，只放置带!default的初始值：例如@primary-color: #1890ff !default;。 - 再建一个
vars-user.less（或由构建脚本生成），其中写入没有!default的强制赋值：@primary-color: #ff6b6b;。 - 主入口严格按顺序导入：
@import 'vars-base.less'; @import 'vars-user.less'; @import 'components/button.less';。 - 避免在组件中重复导入变量文件。变量已在顶层注入，重复导入反而会破坏顺序。
这套方案的关键在于顺序和分层：基础变量数据库提供兜底，用户变量文件做强制覆盖，组件文件只消费不声明。这样一来，所有变量在编译前就拥有确定的依赖链，不会再出现“明明写了却用不上”的情况。
编译后看不到!default，但它决定了整个依赖链的起点
!default 在最终输出的 CSS 中不可见，它如同一个隐形开关，在编译期决定了所有基于该变量的计算是否正确。例如 @border-radius: 4px !default; 没有生效，那么所有 .btn { border-radius: @border-radius; } 都会使用错误的值。更棘手的是，直接查看 CSS 文件找不到任何线索——错误发生在编译期，根源藏在 import 顺序和文件依赖链中。
其中最容易被忽视的一点是：node_modules 中的第三方 Less 库（比如 antd 的 theme 文件），如果也定义了同名变量，并且先于你的配置被 @import，那么你的 !default 就会被“截胡”。这类 bug 定位起来极为费劲，因为从 CSS 输出上完全看不出异常。
