transparentize() 和 darken() 是编译期颜色运算工具，rgba() 报错因首参非 Sass color 类型（如带引号字符串或 CSS 变量），正确写法是 $primary: #3498db 后调用 rgba($primary, 0.6) 或更推荐 transparentize($primary, 0.3)。
transparentize() 和 darken() 是最常用、也最容易出错的两个函数，它们不是“语法糖”，而是编译期颜色运算工具——这意味着所有结果都在 CSS 输出前就固定了，无法响应用户系统主题或运行时状态。
为什么 rgba() 在 Sass 里经常报错？
错误通常长这样：Argument `$color` must be a color。根本原因只有一个：你传给 rgba() 的第一个参数不是 Sass 能识别的 color 类型。
- 写成
$primary: "#3498db"（带引号）→ 字符串，不是 color - 写成
rgba(var(--primary), 0.6)→ CSS 变量是运行时值，Sass 编译时根本看不到它 - 正确做法是
$primary: #3498db（无引号），再用rgba($primary, 0.6)
rgba() 返回的是一个“冻结”的 rgba 字符串，后续不能再对它调用 lighten() 或 mix()；而 transparentize($primary, 0.3) 返回的是可继续运算的 color 类型，语义更清晰、维护性更强。
transparentize() vs opacify()：什么时候该用哪个？
两者都只操作 alpha 通道，不碰 hue/saturation/lightness，但方向相反：
立即学习“前端免费学习笔记（深入）”；
-
transparentize($color, $amount)：让颜色更透明，$amount越大越透（0 = 不变，1 = 完全透明） -
opacify($color, $amount)：让颜色更不透明，$amount是“增加的不透明度”，不是目标值（比如opacify(rgba(0,0,0,0.5), 0.2)→rgba(0,0,0,0.7)） - 别混用：
transparentize(opacify($c, 0.1), 0.1)看似抵消，实则因浮点精度和舍入可能得不到原色
老项目若还在用 fade-out() / fade-in()，注意 Sass 4.0+ 已将其标记为弃用，优先换掉。
darken() 和 lighten() 的对比度陷阱
这两个函数按 LCH 模型调整 lightness，看似简单，但极易导致可访问性问题：
- 从浅灰背景如
#f0f0f0调用lighten($color, 5%)得到#f5f5f5，和白色文字搭配时对比度常低于 WCAG AA 标准（4.5:1） - Sass 不会警告你这点，必须手动用 DevTools 的无障碍面板校验
- 关键文本色（如
$text-primary）建议单独定义，避免靠darken(lighten($base, 10%), 5%)这类链式推导
深色模式适配时，别用 Sass 生成两套变量再靠 @media (prefers-color-scheme: dark) 切换——那套值在编译时就写死了。改用 HSL 变量 + calc()，例如：--l: 55%; background-color: hsl(var(--h), var(--s), calc(var(--l) - 10%));
CSS 变量里存的颜色怎么加透明度？
这是最常卡住的地方：Sass 编译期无法解析 var(--primary)，所以 transparentize(var(--primary), 0.2) 必然失败。
- 唯一可靠方案是把颜色拆成 R/G/B 三变量：
--primary-r: 52; --primary-g: 152; --primary-b: 219，再用rgba(var(--primary-r), var(--primary-g), var(--primary-b), 0.6) -
color-mix()或color(from ...)目前在 Firefox 和 Safari 支持不稳定，2026 年中仍不宜用于生产环境 - 如果必须 JS 控制，那就老老实实读取
getComputedStyle后解析 hex/rgb 字符串——别指望 Sass 帮你跨过编译期和运行期的鸿沟
核心记住一点：Sass 颜色函数只在编译期生效，一旦落到 CSS 变量层面，它就彻底脱离了 Sass 的类型系统。想动态，就得换思路——要么提前拆解，要么交给 JS 或原生 CSS 计算。
