直接写 margin: 1rem 在团队项目中易失控，因其缺乏语义、难以统一响应式缩放且维护成本高；应使用 sass 的 gutter($n, $scale) 函数，以数字档位映射物理值并支持断点缩放，仅用于结构性间距，配合文档对齐设计标注。
为什么直接写 margin: 1rem 在团队项目里很快会失控
因为“1rem”不是语义化的，它只代表一个固定值，没人知道它对应设计稿里的“小间距”还是“卡片分隔”，更没法统一响应式缩放。当设计师说“所有卡片上下间距从 16px 调到 20px”，你得 grep 全项目改几十个地方——而且漏改一两处根本发现不了。
- 不同组件对“中等间距”的理解可能不一致：
margin-bottom: 1.5rem在按钮里是合理，在表单里可能就撑开太多 - 移动端需要压缩间距时，硬编码的
rem值无法批量缩放，只能加媒体查询覆盖，代码膨胀 - Sass 的
@function能把“间距”变成可计算、可命名、可配置的单元，比如gutter(2)表示第二档栅格间距
怎么用 Sass 写一个真正能落地的栅格间距函数
核心不是炫技，而是让函数参数直觉、输出可控、扩展方便。推荐用数字档位（1–6）映射到物理值，并预留断点缩放钩子。
- 定义基础单位：
$base-gutter: 8px，所有间距基于它倍数生成（1 → 8px,2 → 16px…） - 函数签名保持简单：
@function gutter($n, $scale: 1) { @return $base-gutter * $n * $scale; } - 在断点里调用时传缩放系数：
margin: gutter(3, 0.75)，比写@media (max-width: 768px) { margin: 12px }更可靠 - 避免用字符串做参数（如
gutter('md')），后期搜索和类型检查都困难；数字档位配合注释更易维护
常见错误：把 gutter() 当万能胶水乱塞
函数本身没毛病，但滥用会让样式逻辑反向依赖——比如在某个组件里写 padding: gutter(4)，结果发现它和父容器的 margin: gutter(2) 叠加后视觉过重，又不敢动函数，只能加 !important 覆盖。
- 只对**结构性间距**用
gutter()：容器间、区块间、列表项间；组件内部微调（如图标和文字间距）用具体值或独立变量 - 禁止在同一个选择器里混用：
margin: gutter(2) gutter(1)看似省事，但横向/纵向语义丢失，后续想单独调纵向值就得拆开重写 - 如果某页需要全局缩小 10% 的间距，别改函数体，改
$base-gutter或顶层$scale变量——函数只是计算工具，不是策略中心
如何让设计师也能看懂你在用什么间距档位
他们不需要懂 Sass，但需要知道 gutter(3) 对应 Figma 里的哪个标注层。关键是在变量命名和文档上做轻量对齐。
- 在
_variables.scss顶部加注释：// gutter(1) = 8px → “紧凑” / gutter(4) = 32px → “区块分隔” - 导出一份极简对照表给设计团队（纯文本即可）：
1: 紧凑 / 2: 标准 / 3: 中等 / 4: 宽松 / 5: 卡片外边距 / 6: 页面留白 - 禁止出现无注释的魔法数字：
margin-top: gutter(7)必须带行注释说明用途，否则半年后谁也想不起这 7 是哪来的
实际用起来最麻烦的从来不是写函数，而是坚持不让任何人绕过它直接写死像素值——尤其当 deadline 逼近时，那个 margin: 12px 的诱惑力，比任何技术方案都真实。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
