魔法数字会让维护成本指数级上升，因其缺乏语义、散落各处、无法集中管控；Less变量通过语义化命名、分层设计（原子/系统/契约层）和@import(reference)模块化引用，强制将值与上下文绑定，实现可预测、可复用、可主题化的样式管理。
直接用 16px、#007BFF、z-index: 999 写样式，不是在写 CSS，是在埋雷——改一个值，得全局搜、手动对、反复测，还经常漏。
为什么“魔法数字”会让维护成本指数级上升
魔法数字不是指“神秘的数值”，而是指那些没上下文、无语义、无法推演的硬编码值。比如：margin: 24px 不告诉你这是「卡片和标题之间的标准间距」，color: #e74c3c 也不说明它是「错误态主色」。一旦设计系统调整，或需要适配深色模式，这些散落各处的数字就变成不可控变量。
Less 的变量不是语法糖，是把「值」从样式声明中抽离、绑定语义的强制约束机制。它逼你回答一个问题：这个数，代表什么？
- 所有基础值必须收敛到一个统一文件（如
variables.less），禁止跨文件重复定义同名变量 - 变量名必须带语义，
@space-md比@spacing-16更可靠；@color-error比@red-500更可维护 - 禁止在选择器里直接写单位混合表达式，如
margin: @space-md + 1em—— Less 编译时单位不自动归一，结果可能是margin: 16px 1em，CSS 解析失败
变量定义要分层，不能只靠一个 @primary-color
大型项目里，颜色/间距/z-index 都不是单一维度。一个 @primary-color 可能覆盖按钮、链接、边框、描边……但它们在视觉权重、可访问性对比度、状态变化逻辑上完全不同。
立即学习“前端免费学习笔记（深入）”；
正确做法是按使用场景拆解变量层级：
- 基础原子层（只定义单位与基准）：
@unit: 4px、@font-size-base: 16px - 设计系统层（语义化档位）：
@space-xs: @unit * 1、@space-sm: @unit * 2、@space-md: @unit * 4 - 组件契约层（带上下文）：
@button-padding-y: @space-sm、@card-margin-bottom: @space-md
这样改主题时，只需动原子层或设计系统层；加新组件时，复用已有档位，不新增魔法数字。
@import (reference) 是防止变量污染的关键
很多人把所有变量塞进一个 variables.less，再用 @import "variables" 全局引入——结果是每个组件都继承了全部变量，哪怕只用到 @space-sm，也加载了整套 z-index 和颜色体系，构建体积膨胀，命名冲突风险高。
@import (reference) 让变量只作为“引用存在”，不输出 CSS，也不污染当前作用域：
@import (reference) "variables/spaces"; @import (reference) "variables/colors";
它相当于告诉 Less：“我只借你的变量来计算，别把它们编译成实际样式。”配合模块化路径（如 variables/spaces），还能按需加载、避免循环依赖。
响应式变量重定义为何总失效？因为你在写无效语法
在 @media 块里写 @space-md: 24px，Less 不报错，但也不会生效——变量作用域在编译期就已冻结，@media 是运行时规则，两者根本不在一个执行平面。
真正可行的方式只有两种：
- 用条件 mixin：
.spacing-md() when (@breakpoint = desktop) { margin: @space-lg; }，配合构建时传入参数 - 预定义多套变量集：
@space-mobile/@space-tablet，再用媒体查询 mixin 分别注入：.media-desktop { .spacing-md() { margin: @space-desktop; } }
最常被忽略的一点：变量名本身不能含媒体查询逻辑，比如 @space-md-mobile 这种命名看似清晰，实则破坏了「同一语义在不同设备下取不同值」的设计契约，后期扩展断点时会迅速失控。
