Less变量写在后面也能被前面使用是因为其采用延迟加载机制，即编译器先扫描全部变量定义再统一替换，但仅限于同一作用域内；局部变量不因延迟加载而突破作用域限制。
Less变量为什么写在后面也能被前面使用
因为Less变量是延迟加载（lazy evaluation）的，不是按代码顺序逐行执行，而是在整个文件解析完成后再统一查找和替换。这意味着@primary-color定义在文件末尾，只要它被声明过，前面所有用到@primary-color的地方都会被正确替换。
变量提升 ≠ JavaScript hoisting
Less的“提升”不是把声明移到顶部执行，而是编译器先扫描全部@变量名:语句收集定义，再遍历所有引用处做文本替换。它不关心位置，只认是否定义过。
- 变量未定义时会报错：
variable @missing is undefined - 同名变量后定义覆盖前定义（非作用域叠加，是纯覆盖）
- 嵌套块内重新声明同名变量，仅在该块内生效，不影响外部
容易踩的坑：局部变量 + 延迟加载的混淆
很多人以为“写在后面能用”就等于“全局可穿透”，但局部变量并不受延迟加载“豁免”：
-
@color: red;在根作用域定义 → 全局可用 -
.box { @color: blue; color: @color; }→@color仅在.box块内有效 - 若在
.box外写body { color: @color; }，仍取根作用域的red，不会因为.box里重定义就变 - 但如果你把
@color: blue;写在.box块之后、body规则之前，且在根作用域 —— 那么body就会用上blue，因为它属于全局延迟解析范围
什么时候延迟加载会失效
延迟加载只对静态变量定义生效；一旦涉及运行时行为，就不再适用：
立即学习“前端免费学习笔记（深入）”；
-
less.modifyVars()是 JavaScript 运行时调用，和 Less 编译期的延迟加载无关 - 变量插值用于选择器（如
@name: header; .@{name} { ... }）必须在使用前定义，否则插值为空或报错 - 在
calc()或url()中引用变量时，如果变量值含非法字符（比如未加引号的空格），可能触发解析失败，此时位置无关，直接中断编译
真正关键的不是“能不能写在后面”，而是“这个变量是否在当前作用域链中被明确定义过”。延迟加载只是让定义位置更自由，没解除作用域规则。
