直接用linear-gradient写多方向渐变易出错，因原生语法中角度值（如45deg）与关键字（如to bottom right）不可混用，且浏览器对to top等写法解析存在差异，手写易漏单位、写反方向或忽略Safari兼容前缀。
为什么直接用 linear-gradient 写多方向渐变容易出错？
因为 CSS 原生 linear-gradient 的方向参数语法不统一：角度值（如 45deg）和关键字（如 to bottom right）不能混用，且浏览器对 to top 这类写法的解析存在细微差异。手写时一不留神就会产出无效渐变，尤其在响应式或主题切换场景下，重复写一堆相似规则极易漏掉单位、写反方向或忽略旧版 Safari 的兼容前缀。
gradient-direction 参数怎么设计才真正通用？
关键不是把所有方向枚举出来，而是统一成「可计算的数值输入」。推荐只接受两类值：number（角度，单位必须是 deg）或 string（仅限 "to top"、"to right" 等标准关键字）。SCSS 无法运行时判断单位类型，所以得靠开发者约定——传 90deg 就走角度路径，传 "to right" 就走关键字路径，Mixin 内部不做自动转换，避免歧义。
示例用法：
@include gradient(linear, 135deg, #f00, #00f);
@include gradient(linear, "to bottom right", #333, #fff);
如何让颜色列表支持任意长度且避免编译报错？
SCSS 的 join() 和 nth() 对空列表或单色处理脆弱。必须提前校验：$colors 至少两个值，且每个值能被 type-of() 判为 color 或合法 CSS 字符串（比如变量名 $primary）。否则编译期直接报 "Invalid CSS after..." 错误。
立即学习“前端免费学习笔记（深入）”；
- 用
@if length($colors) 拦截单色调用 - 用
@each $c in $colors { @if type-of($c) != color and not str-index($c, "$") }粗筛非法值（允许变量名含$，但拒绝数字或布尔） - 生成渐变时，对第一个和最后一个色标不加位置，中间色标用
#{percentage($i / (length($colors) - 1))}均匀分布
旧版 Safari（iOS 9.3–12）需要 -webkit-linear-gradient 吗？
需要，但仅当明确目标用户包含这些版本时才开启。现代项目通常已放弃支持，强行加前缀反而增大 CSS 体积。Mixin 里用布尔开关 $legacy: false 控制是否输出前缀版本，而不是默认开启。
实际建议：
- 若项目 .browserslistrc 包含
safari >= 13，直接删掉-webkit-分支 - 保留前缀时，角度值必须转成
deg单位（Safari 不认turn或无单位数字） - 关键字方向如
"to bottom"在 WebKit 前缀中必须写成bottom（去掉to），否则无效
真正麻烦的从来不是写法本身，而是不同方向参数在各浏览器里对「起始点」的定义偏差——比如 to top 在 Chrome 是从下往上铺，在某些旧 Android WebView 却反向。测试时务必用真实设备抓 Network 面板看最终生成的 CSS 是否符合预期。
