!default仅在变量首次声明前生效，非后备值；一旦变量被声明（含空声明），后续!default均失效，且不支持表达式、递归引用或Mixin内稳定使用。
Less中!default到底什么时候生效
它只在变量**尚未被声明过**时才起作用，不是“优先级更低的赋值”，也不是“后备值”。一旦前面代码里出现过同名变量声明（哪怕只是@color: ;），!default就彻底失效。
常见错误现象：@primary-color: #007bff;写在引入variables.less之前，但里面又有@primary-color: #333 !default;——结果@primary-color还是#007bff，根本没走!default分支。
- 使用场景：适合放在基础库（如Bootstrap Less）顶层变量文件末尾，给使用者留出覆盖入口
- 参数差异：它不接受函数调用或表达式作为右侧值，比如
@size: unit(16px, px) !default;会报错，必须是静态值或已定义变量 - 注意顺序：Less按从上到下解析，
!default声明必须出现在所有可能的首次赋值之后
!default和普通变量声明混用容易踩的坑
很多人以为!default像CSS自定义属性那样支持“层叠覆盖”，其实Less里变量是编译期一次性绑定的，没有运行时重绑定概念。
典型翻车现场：@spacing: 8px !default; 和 @spacing: @spacing * 2; 写在一起——后者会直接报Recursive variable definition for @spacing，因为@spacing还没真正“落定”就被引用了。
立即学习“前端免费学习笔记（深入）”；
使用 ImageMagick 的 convert 和 mogrify 命令进行批量图像处理，支持调整大小、裁剪、水印和格式转换。与 libvips 集成以实现高性能缩略图生成。
- 不能在
!default声明后立刻基于它做计算，得等它被真实赋值后才行 - 多个
!default对同一变量重复声明，只有第一个有效，后面全被忽略（无警告） - 如果变量来自
@import，导入顺序决定谁能赢：后导入的!default无法覆盖先导入的普通声明
如何安全地实现主题变量可配置
别依赖!default单打独斗。实际项目里更可靠的做法是分层 + 显式开关。
比如把用户配置抽成user-config.less，开头加@theme-overrides: true;，然后在主变量文件里写.when (@theme-overrides = true) { @primary-color: #ff6b6b; }——这样逻辑清晰、调试可见、IDE也能跳转。
- 避免把
!default塞进.mixin里，它在Mixin作用域内行为不稳定 - Webpack/Vite里用
less-loader的modifyVars传参，本质是字符串替换，会绕过!default机制，要同步维护两套逻辑 - CI构建时若用
lessc命令行，确保--include-path顺序正确，否则!default可能被node_modules里的同名变量截胡
编译后CSS里看不到!default痕迹，但它影响整个依赖图
!default本身不输出任何CSS，但它决定了哪些变量值最终进入计算链。一个被!default兜底的@border-radius，如果上游没人赋值，就会导致所有用到它的.btn、.card样式都按默认值渲染——而你可能只改了一个颜色变量，却忘了半数UI依赖这个半隐半现的半径值。
最容易被忽略的是嵌套层级深的间接依赖：比如ui-kit/typography.less里@line-height-base !default，被ui-kit/button.less引用，再被你的app/components/header.less导入——这时候你在header.less顶部加@line-height-base: 1.4;，已经晚了。
- 查变量来源最稳的方式是删掉所有
!default，看哪里报错；再逐个加回来定位生效点 - VS Code装Less IntelliSense插件，悬停变量能看到“defined in xxx.less (default)”提示，比肉眼扫快得多
