less变量必须用@前缀声明，作用域限于当前选择器，全局变量需统一在variables.less中定义并用!default确保可覆盖；混合宏（.mixin）更适合封装带逻辑的样式片段。
Less变量声明必须用@前缀，且作用域规则和CSS原生不同
Less里没写@的“变量”根本不会被识别，比如primary-color: #007bff;会被当成普通属性丢进输出里。更关键的是作用域：嵌套规则里的@变量默认只在当前选择器内有效，不像CSS自定义属性那样天然全局。
实操建议：
- 所有主题色、间距、断点统一在
variables.less里用@声明，顶部加// 全局变量注释，方便搜索 - 避免在
.btn { @size: 14px; }这种块级作用域里定义跨组件复用的值，容易漏掉!default导致覆盖失败 - 想让变量穿透嵌套，得显式用
@{variable-name}插值语法，比如background: @{primary-bg};
用!default实现主题变量可覆盖，但顺序和导入路径决定成败
Less没有“变量重定义”概念，只有“首次赋值生效”。!default不是保险丝，而是“如果这个变量还没被赋过值，就用我”。所以@primary-color: #007bff !default;写在基础库文件里，项目里再写@primary-color: #28a745;才有效——前提是项目变量文件在基础库之后@import。
常见错误现象：
- 主题色改了但按钮没变：检查
@import顺序，项目变量必须在框架变量之后 - 本地开发正常，构建后还原成默认色：Webpack的
less-loader可能并行处理多个入口，把变量文件拆到不同chunk里，导致作用域隔离 -
!default写在.mixin内部无效，它只对顶层@变量起作用
混合（.mixin）比纯变量更适合管理带逻辑的CSS片段
单纯颜色、字号用变量够用，但像“响应式字体缩放”“阴影层级组合”“边框+圆角+过渡三件套”，硬塞进变量会失控。这时候.mixin才是Less的核心价值。
使用场景举例：
- 需要根据
@theme切换整套配色时，用.theme-mixin()包裹所有相关规则，比逐个替换@变量更安全 - 移动端适配中，
.responsive-font(@base-size)内部用@media和calc()生成多断点样式，变量做不到这点 - 参数差异：mixin支持默认参数（
.btn-style(@bg: @primary-color, @hover: darken(@bg, 10%))），变量不支持函数式计算
编译后CSS体积和维护成本，取决于变量粒度是否合理
把每个像素值都抽成@spacing-xs@spacing-sm…看着整齐，实际会导致变量表膨胀、命名纠结、修改成本翻倍。Less变量不是越多越好，而是要卡在“改一处影响N处”的临界点上。
性能与兼容性提示：
- 过度细分变量会让
variables.less变成字典，新人不敢动，老手懒得查——最终大家直接写margin: 8px;绕过体系 - 所有
@变量在编译时展开为静态值，不产生运行时开销，但错误的粒度会让CSS选择器重复率飙升（比如每个组件都@import同一套变量，又各自定义同名@） - 别用
@模拟CSS自定义属性行为（如:root { --color: @primary; }），Less不支持运行时读取，纯属徒增编译复杂度
真正难的从来不是怎么写@，而是判断哪些值值得被抽象、哪些该留在具体规则里——这得看团队协作节奏和UI迭代频率，没法靠工具解决。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
