应统一用 sass map 管理间距变量，如 $spacers: ("xs": 4px, "sm": 8px, "md": 16px)，所有 margin/padding 均通过 map-get 调用，并封装 @mixin m() 支持语义化快捷写法，禁用硬编码和混用单位。
为什么直接写 margin: 1rem 1.5rem 2rem 0.5rem 不利于维护
边距值分散在各处，改一个间距（比如从 1rem 升级为 1.25rem），就得全局搜、逐个换，漏掉一两个就导致视觉不一致。更麻烦的是，不同组件对“小间距”“中间距”的理解可能完全不同——Card 认为 0.75rem 是小，Button 却用 0.5rem，这种隐式约定没法被工具检查，只能靠人盯。
- 所有间距值必须来自同一组变量，不能硬编码数字或单位
- 避免用
rem/em混用：Sass 中统一用px或统一用rem，否则数学运算会出错（比如1rem + 8px在未启用unitless转换时直接报错） - 别在
@mixin里做条件判断来“智能缩放”边距，比如“移动端自动减半”——这会让调用方失去控制权，也增加调试难度
$spacers 数组定义 + map-get 查找是最稳的起点
用 Sass map 存一组命名间距，比一堆独立变量更易扩展和遍历。比如 $spacers: ("xs": 4px, "sm": 8px, "md": 16px, "lg": 24px, "xl": 32px)，后续所有 margin / padding 都从这里取值，而不是重复写 8px。
- 定义时用
px最安全：避免rem基准变动导致计算偏移 - 键名保持语义化（
"sm"、"md"），别用"margin-1"这类纯序号，否则无法表达设计意图 - 查值必须用
map-get($spacers, "sm")，别直接写$spacers("sm")（语法错误） - 加减运算要显式转换单位：比如
map-get($spacers, "md") * 2可行，但map-get($spacers, "md") + 2会报错——因为2是无单位数，Sass 不允许混算
用 @mixin 封装 margin 和 padding 的四向快捷写法
手动写 margin-top: map-get($spacers, "sm") 太啰嗦，封装成 @mixin m(sm) 或 @mixin mt(sm) 才实际可用。
- 支持单参数：
@include m(sm)→ 四边等距；双参数：@include m(sm xl)→ 上下/左右；三参数：@include m(sm xl md)→ 上/左右/下；四参数：@include m(sm xl md xs)→ 上右下左 - 方向后缀必须严格对应 CSS：用
mt（margin-top）、pr（padding-right），别自创mr（容易和 margin-right 混淆） - 传入非法键名（如
@include m(invalid)）时，Sass 默认静默失败，建议加@warn提示：“Unknown spacer key ‘#{$key}’” - 不要在 mixin 里写
!important——它破坏层叠逻辑，且无法被后续样式覆盖
Sass 数学运算在边距中的真实限制
想让卡片内边距是外边距的 1.5 倍？写 padding: map-get($spacers, "md") * 1.5 看似合理，但得小心单位丢失和精度问题。
-
16px * 1.5得到24px，没问题；但15px * 1.5得到22.5px，某些老浏览器渲染模糊，慎用于 border 或分割线场景 - 用
round()或floor()主动取整：比如round(map-get($spacers, "sm") * 1.3) - 别对
em做乘除：父元素字体大小变化时，1.2em * 2的结果不可预测，优先用px或rem配合固定根字号 - 嵌套计算要括号明确优先级：比如
(map-get($spacers, "lg") - map-get($spacers, "sm")) / 2，不加括号可能被解析为除法优先于减法
真正难的不是写出能跑的代码，而是让设计师改一个“中等间距”时，所有 mt、mb、pl、pr 都同步响应，且不意外影响按钮圆角或表格行高——这要求每个数学运算都可追溯、可验证，而不是靠“应该没问题”去赌。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
