直接写 padding: 16px 会埋下维护雷，因随意数值导致设计系统脱节、重构漏改；应通过 Sass map 统一管理间距值并封装容错函数 spacing() 确保可维护性。
为什么直接写 padding: 16px 会埋下维护雷
项目初期随手写几个 padding 值看似省事，但很快会出现：按钮用 12px，卡片用 16px，表单项又冒出 14px——这些数字没有来源、无法对齐设计系统、重构时改一处漏十处。Sass 的 map 不是用来炫技的，它是把“间距决策权”从每个 CSS 声明里收回来的第一道防线。
用 $spacings Map 定义可枚举的间距层级
别用散列变量（如 $spacing-xs、$spacing-sm），直接建一个语义化 map，让所有间距值有唯一源头：
$spacings: ( 'none': 0, 'xxs': 2px, 'xs': 4px, 'sm': 8px, 'md': 12px, 'lg': 16px, 'xl': 24px, 'xxl': 32px, 'xxxl': 48px );
这样做的关键好处是：所有间距必须来自这个集合，避免新增随意数值；后续加设计 token、导出给 Figma 插件、甚至生成 JS 可用的 spacing 对象都基于同一份数据。
- 命名不推荐用像素值（如
'16'），容易和具体尺寸耦合，改设计系统时 rename 成灾难 - 值可以是
rem或em，但全项目必须统一单位，px在响应式场景下会限制缩放能力 - Map 键名大小写需一致（建议全小写 + 连字符），避免在
map-get()时因大小写错误静默失败
通过 @function spacing() 安全读取 Map 值
直接 map-get($spacings, lg) 写死在样式里？不行——一旦查不到键，Sass 编译直接报错，且无法 fallback。必须封装一层带容错的函数：
立即学习“前端免费学习笔记（深入）”；
@function spacing($key) {
@if not map-has-key($spacings, $key) {
@warn "Unknown spacing key '#{$key}' in $spacings map. Available keys: #{map-keys($spacings)}.";
@return null;
}
@return map-get($spacings, $key);
}之后就能安全使用：
.card {
padding: spacing(lg);
}
.btn {
margin: spacing(sm) spacing(md);
}- 函数返回
null而不是抛错，让未定义键的样式被浏览器忽略（CSS 层面失效），而非阻断整个 Sass 编译 - 警告信息里明确列出所有可用键，新人一眼就知道该选什么
- 不要在函数里做单位转换（如
* 1rem），单位应由 Map 值本身决定，保持原子性
生成工具类时，避免用 @each 直接输出全部组合
很多教程教这么写：
@each $key, $value in $spacings {
.p-#{$key} { padding: $value; }
.m-#{$key} { margin: $value; }
}结果生成几十个几乎不用的类（比如 .p-xxs），体积膨胀、CSS 选择器冗余、开发者也记不住。更务实的做法是：
- 只生成高频组合：如
.p-sm、.p-md、.p-lg、.px-md、.py-lg，用白名单控制 - 用
map-keys()动态读取，但加index()判断或if条件过滤，而不是无差别遍历 - 如果项目用 Tailwind，就别自己造——直接配
theme.spacing，Sass Map 只作源数据同步用
真正难的不是写出来，是让团队所有人习惯查 Map 而不是凭感觉敲数字。那个 spacing() 函数的警告提示，比任何文档都管用。
