Less变量本质是编译期全文件线性扫描替换，非真正提升；跨文件依赖严格受@import顺序制约，嵌套中重定义会全局覆盖，CSS变量与Less变量机制不兼容、不可混用。
Less变量根本不是“提升”，而是全文件扫描替换
所谓“变量提升”是误解。Less编译器在解析阶段会**线性扫完整个文件**，收集所有@xxx:定义，再统一做字符串替换——它不执行、不求值、不创建作用域。你写@color: red;在文件末尾，前面也能用，不是因为“提升”，而是因为编译器还没开始输出CSS前就已看到并记住了这个定义。
问题出在跨文件场景：一旦@import顺序错乱，扫描就断链。比如button.less里用了@primary-color，但variables.less在它之后才被@import，编译器在处理button.less时根本没见过@primary-color，直接报variable @primary-color is undefined。
- 单文件内“后定义前使用”能工作，只是编译器扫描顺序的副作用，不是语言特性
- 跨文件依赖必须严格按
@import顺序保证“先定义、后使用” -
@import (reference)不影响变量注入时机，只抑制CSS输出——变量照样按导入位置进入作用域
嵌套中重定义变量会污染全局，不是局部覆盖
Less没有词法作用域。&__header { @gap: 16px; }不是给&__header建了个新作用域，而是把@gap整个重写了。后续所有引用（包括同级的&__body或文件后半部分）拿到的都是16px，哪怕你本意只想改头部间距。
这种线性覆盖行为会直接打乱样式应用顺序：原本.card__header该用8px，结果因后面某处重定义变成了16px，而.card__body也跟着变了——你没动它，但它“被顺带改了”。
立即学习“前端免费学习笔记（深入）”；
- 别用嵌套块内赋值控制局部样式，
&只影响选择器生成，和变量无关 - 要用局部配置，必须封装成
.mixin(@gap: 8px) { padding: @gap; }，显式传参 -
!default只在变量首次赋值时生效，不能回滚或条件覆盖，多文件同名变量以最后@import为准
@import顺序决定最终CSS层叠顺序，不是书写位置
你在index.less里把@import "button.less";写在第100行，它实际会被编译器提到文件最顶部展开。最终CSS中.btn规则的位置，取决于button.less在@import列表中的顺序，而不是你在源码里把它放在reset还是layout后面。
更麻烦的是嵌套@import：如果button.less自己又@import "mixins.less";，那mixins.less的内容插入点，由button.less被谁导入、何时导入决定——你根本没法从index.less里直观判断最终顺序。
- 所有
@import必须集中放在入口文件顶部，按variables → mixins → base → components硬性排序 - 组件文件内部禁止
@import，否则依赖树失控 - 用
lessc --verbose可查看实际展开顺序，比猜靠谱
CSS变量(--x)和Less变量(@x)混用必然错乱
@primary-color: #007bff;编译后消失，--primary: #007bff;必须存活在最终CSS中且位置正确。前者是编译期文本替换，后者是运行时继承链查找——两者机制完全不兼容。
常见翻车点：:root { --primary: red; }写在components/button.less末尾，但该文件被提前@import，导致.btn { color: var(--primary); }查不到值；或者在Vue单文件组件里定义--primary，却在另一个组件里用var(--primary)，根本没有继承链。
- 别指望
var(--x, fallback)的fallback能替代@x: red !default，语义完全不同 - 需要运行时响应，就用
--x并确保声明在使用点之前（DOM渲染流顺序） - 需要编译期复用，就用
@x并严格控制@import顺序——二者边界必须划清
@import怎么排就怎么拼”。变量看似灵活，实则脆弱；嵌套看似隔离，实则污染；混用CSS变量看似省事，实则埋雷。所有异常，都源于把编译期文本处理当成了运行时作用域管理。 
