less无isdefined()等变量检测机制，未定义变量直接报错；可靠方案是显式声明默认值并利用后定义覆盖规则，或用mixin参数默认值模拟条件逻辑。
Less 中没有 isdefined() 或类似内置函数
Less 本身不提供运行时变量存在性检测机制，@variable-name 如果未定义，编译时直接报错：Variable @xxx is undefined，不会静默 fallback。这意味着你不能像 JavaScript 那样写 if (typeof @color !== 'undefined') {...} —— 这在 Less 里语法非法，也不被解析。
真正能用的路径只有一条：**提前声明变量，并利用 Less 的变量覆盖规则和作用域特性做“默认优先”设计**。
用 @variable: value; 声明默认值，再让使用者覆盖
Less 变量是“先定义后使用”，且同名变量后定义的会覆盖前一个（在同一作用域或更内层作用域）。因此最可靠的做法是：在库/组件顶层文件中，**显式赋予默认值**，把“未定义”这个状态从逻辑上消除。
- 在你的
defaults.less里写：@primary-color: #007bff; - 在用户项目中引入顺序为：
@import "defaults.less"; @import "user-variables.less"; -
user-variables.less可以安全地重写：@primary-color: #28a745;—— 它会覆盖默认值 - 后续所有样式都直接引用
@primary-color，无需检测
这个模式本质是“约定优于配置”，不是检测，但效果等价：只要用户没覆盖，就用默认；覆盖了，就用用户的。它稳定、可预测、零 runtime 成本。
避免用 !default 的常见误解
!default 看似是“如果未定义才赋值”，但它只在变量**首次声明时生效**，且仅对同一作用域内、尚未被赋值的变量起作用。很多人误以为它能跨文件或动态检测，实际很容易踩坑：
- 错误写法（期望在用户文件里“补默认”）：
@primary-color: #007bff !default;—— 如果该变量已在前面某处（哪怕只是@primary-color:空声明）出现过，!default就失效 - 不同
@import顺序下行为不一致：把带!default的放后面，可能根本不起作用 - 无法用于条件分支：
.btn { color: if(@primary-color, @primary-color, #6c757d); }会报错，因为@primary-color未定义时编译器已终止
所以 !default 只适合在基础变量文件内部做“多级 fallback”，比如：@text-color: @body-text-color !default; @body-text-color: #333 !default;，但绝不该作为对外暴露的“检测接口”。
真需要条件逻辑？用 Mixin + 参数默认值模拟
如果你的组件必须支持“有变量用变量，没变量走兜底样式”，唯一可行的间接方案是封装成 mixin，并把变量作为参数传入，利用 Less 的参数默认值机制：
.button-style(@bg: #007bff, @color: #fff) {
background-color: @bg;
color: @color;
}
然后调用时：
- 用户定义了
@my-btn-bg：写.button-style(@my-btn-bg); - 用户没定义：直接写
.button-style();，自动用默认值
这绕开了变量存在性问题，把控制权交给调用方，也更符合 Less 的静态编译模型。不过要注意：mixin 不能替代全局变量语义，比如你想在多个 selector 里复用同一个颜色，还是得回到第一种“显式声明默认值”的方式。
真正难处理的是跨文件、跨构建流程的变量注入场景——这时候别硬扛 Less，该上 CSS 自定义属性（--primary-color）配 JS 检测就上，Less 不是万能胶。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
