Sass 1.79+已支持多空间感知，但adjust-color()等旧函数不感知空间，必须用color.adjust($space: "oklch")等新API才能实现视觉均匀的精确调整。
直接说结论：Sass 1.79+（2026年中起）已全面支持 sass:color 模块的多空间感知能力，但「精确调整」的前提是——你得先让颜色知道自己在哪个空间里，否则 lightness、chroma 等参数会按 sRGB 错误解释。
为什么 adjust-color() 在新版本里反而容易调错
旧版 Sass 把所有颜色都当 sRGB 处理，adjust-color($c, $lightness: 10%) 实际是在 RGB 立方体上沿灰度轴加减，视觉上不均匀。新版保留该函数作兼容，但它**不感知颜色空间**，传入 oklch(50% 0.2 240) 后仍按 sRGB 解析通道，结果可能偏色或失真。
- 除非你明确用
color.adjust()并指定$space: "oklch"，否则别信任何带lightness/saturation的老函数 -
scale-color()同理，它缩放的是当前颜色的「原始通道值」，不是感知均匀值 - 如果你从 CSS 变量读取
color(display-p3 0.8 0.2 0.3)，Sass 默认把它当作 sRGB 解析，color.lightness()返回的是错的
color.adjust() 怎么写才真正精确
这是新版 sass:color 模块里唯一推荐用于「视觉一致调整」的函数。它强制你声明目标空间，且自动做空间转换：
@use "sass:color"; $base: color.oklch(60% 0.15 310); $lighter: color.adjust($base, $lightness: 10%, $space: "oklch"); $darker: color.adjust($base, $lightness: -8%, $space: "oklch");
-
$space必须显式传，不能省略；传"oklch"表示在 OKLCH 空间里调lightness和chroma，视觉变化线性 - 若传
$space: "srgb"，它就退化为旧版行为，慎用 - 对 HWB 颜色，
$space: "hwb"才能正确调whiteness/blackness，传错空间会导致通道被忽略或报错
如何确保输入颜色自带空间信息
Sass 不会自动推断一个十六进制值属于什么空间。你必须用新构造函数显式声明：
立即学习“前端免费学习笔记（深入）”；
- 别写
#ff6b6b→ 改用color.srgb(100% 42% 42%)或color.display-p3(1.0 0.4 0.4) - 从 CSS 变量读取时，用
color.parse(var(--primary))，它能识别oklch()、lab()等语法并保留空间元数据 - 混色操作如
color.mix()要求两个颜色在同一空间，否则会静默转到 sRGB —— 这常是暗色模式下颜色发灰的根源
容易被忽略的边界点
最麻烦的不是不会用，而是用了却没效果，或者效果只在部分浏览器可见：
-
color.to-gamut()默认用method: "relative-colorimetric"，但 display-p3 到 sRGB 的映射在 Safari 和 Chrome 渲染略有差异，别依赖像素级一致 - 输出时 Sass 仍默认降级为
rgba()，即使你全程用oklch()调整 —— 这是向后兼容策略，不是 bug -
color.same($a, $b)比较前会自动转到同一空间，但若其中一个是缺失 alpha 的oklch(50% 0.2 310)，另一个是带 alpha 的oklch(50% 0.2 310 / 0.8)，它们不相等
