大型项目中直接写 margin: 16px 会失控，因它非设计系统而是魔法数字；应统一用语义化间距变量（如 @space-sm）、封装 margin/padding mixin，并避免在媒体查询中重定义变量或混用单位。
为什么直接写 margin: 16px 在大型项目里很快会失控
因为“16px”不是设计系统，只是临时数值。当按钮、卡片、表单控件各自定义自己的 margin，改一处就要全局搜、手动调、反复对齐——这不是写样式，是在修bug。
Less 的变量 + 计算能力，本质是把“间距”从魔法数字变成可推演的规则。比如：@spacing-xs: 4px、@spacing-sm: 8px、@spacing-md: 16px，再用 @spacing-md * 2 表达双倍间距，而不是硬写 32px。
- 所有间距必须基于同一组基础变量（如
@spacing-unit或分档变量），禁止在选择器里直接写像素值 - 避免用
@spacing-md + @spacing-sm这类加法表达式——语义模糊，后期难维护；优先用预设档位：@spacing-lg - 响应式中慎用
calc()套 Less 变量（如calc(@spacing-md + 1em)），编译后可能出错或丢失单位，应先确保单位一致（都用px或都用rem）
如何让 margin 和 padding 共享同一套变量体系
很多人只给 margin 设变量，留 padding 自生自灭，结果内边距和外边距数值不呼应，视觉节奏断层。
关键不是多写几行变量，而是统一命名逻辑和层级关系：
- 定义基础档位时，用语义名而非尺寸名：用
@space-xxs、@space-xs、@space-sm……比@spacing-4、@spacing-8更易协作 - 为
margin和padding分别封装函数（mixin），例如：.m-x(@size) { margin-left: @size; margin-right: @size; }<br>.p-y(@size) { padding-top: @size; padding-bottom: @size; } - 禁止在 mixin 中做单位转换（如把
rem转成px），单位应在变量层就确定好；否则不同设备下缩放行为不可控
响应式间距调整时，@media 里重定义变量为何无效
Less 变量作用域是编译期的，@media 是运行时 CSS 规则，两者不在一个维度。你在 @media (min-width: 768px) 里写 @spacing-md: 24px，编译后不会生效——它只是被忽略的语法错误。
正确做法是用响应式 mixin 或带条件的计算：
- 用
.when条件 mixin 控制输出（适合有限断点）：.spacing-md() when (@breakpoint = desktop) { margin: 24px; }<br>.spacing-md() when (@breakpoint = mobile) { margin: 16px; } - 更通用的方式：定义多套变量集（
@spacing-mobile、@spacing-tablet），再配合媒体查询 mixin 分别注入 - 切记不要在
@media块里重复声明同名变量——Less 不报错但也不起作用，容易误以为“写了就生效”
用 calc() 混合 Less 变量时单位不匹配的典型报错
常见错误信息：Operation on an invalid type 或编译后生成 calc(16px + 1) 这种非法 CSS。
根本原因是 Less 对单位运算极其严格：两个值必须单位相同，或一个是无单位数、另一个带单位且参与乘除（加减不行）。
- 错误写法：
width: calc(@spacing-md + 1em)——px和em不能直接加 - 安全写法：统一转为
rem（如@spacing-md: 1rem），再用calc(@spacing-md + 0.5rem) - 更稳妥的替代方案：用 Less 函数提前算好，比如
@wide-spacing: unit((16px + 16px), px)，再代入margin: @wide-spacing
实际落地最难的不是写变量，是让人不再随手敲 margin: 10px。一旦团队里有人绕过规范，整套体系就会从内部瓦解。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
