Less变量定义中!default关键字为何常被忽略

一个常见的误区：很多人把 !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 输出上完全看不出异常。