Less变量提升是编译期单文件文本扫描，不解决跨文件依赖或作用域隔离；嵌套中重定义会全局覆盖变量值，!default仅在变量未定义时生效。
Less 中的“变量提升”不是真正的作用域提升，它只是编译器在单文件内做的一次性文本扫描，不解决跨文件顺序依赖，也不提供隔离；所谓“覆盖”，本质是后定义的值直接替换全局变量表中的旧值，所有后续引用（包括已编译过的规则）都会拿到新值——这不是意外，是编译模型决定的。
Less 变量提升只在单文件内生效，跨文件必须靠 @import 顺序
你在 index.less 末尾写 @primary-color: #dc3545;，前面的 .btn { color: @primary-color; } 能用上，是因为 Less 编译前已扫完整个文件、统一收集变量再替换。但一旦拆成多个文件：@import "button.less"; @import "variables.less";，而 button.less 里提前用了 @primary-color，就会报 variable @primary-color is undefined。
- @import 是纯文本拼接，不是模块加载，顺序错了就找不到定义
- Webpack 的
less-loader不会重排@import，严格按源码书写顺序执行 -
@import (once)或(reference)都不能改变变量注入顺序，只影响 CSS 输出
嵌套中重写 @variable 不是局部作用域，而是全局覆盖
写 .card { @padding: 16px; &__body { @padding: 24px; } &__header { padding: @padding; } }，&__header 最终用的是 24px，不是 16px。因为 Less 没有块级作用域，&__body 里的 @padding 直接覆盖了当前上下文的变量值，影响所有后续引用。
- 浏览器 DevTools 看不到哪一层改了变量，只能全局搜索
@padding - 已生成的 CSS 不会回溯重算：如果
&__header规则在重定义前就被编译，那它仍用旧值 - 这种“就近覆盖”和 CSS 变量的树状继承完全不同：
.card { --padding: 16px; } .card__body { --padding: 24px; }并不会影响.card__header
!default 不是作用域开关，只对首次赋值有效
@primary-color: #007bff !default; 只在变量**尚未被定义过**时才生效；如果之前已有 @primary-color: #1a1a1a;，后面再写带 !default 的语句完全无效。所谓“默认值”控制，实际靠的是定义位置——必须把 !default 版本放在所有可能覆盖它的语句之前。
立即学习“前端免费学习笔记（深入）”；
- 错误做法：在主题文件里先
@import "vars.less";，再写@primary-color: #ff6b6b;→vars.less里的!default根本没机会触发 - 正确做法：所有
!default定义集中放在入口文件最开头，再@import其他模块 -
!default对 CSS 变量（--x）完全无效，它只作用于 Less 编译期变量
多文件同名变量以最后 @import 进来的为准
两个组件文件都定义 @primary-color，比如 button.less 和 modal.less，最终生效的是最后一个被 @import 的那个值。这不是冲突，是 Less 的设计行为——变量表是扁平、线性、可变的，没有合并逻辑。
- 调试时搜不到源头：DevTools 只显示编译后的 CSS 值，不显示变量来自哪个文件
- lessc --lint 可查重复定义（需 Less 4.0+），但默认不报错，只静默覆盖
- 唯一可靠防线：禁用裸名（如
@color），强制前缀（@btn-primary-bg），所有公共变量单点收口到variables.less
真正难处理的不是“提升”本身，而是它和 CSS 变量运行时机制混用时产生的认知错位——Less 变量在编译后就消失了，而你还在用 DevTools 查 --primary-color 的继承链。
