hsl(from …) 是唯一能安全提取饱和度的现代写法，仅支持源色为 hsl() 或 hwb() 格式，需显式含 s 分量，且须配合亮度重平衡与 clamp 限制范围，其他如 oklch/from、lch/from 均未稳定支持。
hsl(from …) 是唯一能安全提取饱和度的现代写法
目前（2026 年中）只有 hsl(from <color> h s l) 能在主流浏览器中稳定提取并修改饱和度，前提是源颜色本身是 hsl() 或 hwb() 格式。其他如 oklch(from ...)、lch(from ...) 等全部处于草案阶段，Chrome 实验性支持也仅限 color(from ...) 基础形式，且不支持自定义属性回溯（即 from var(--c) 会静默失效）。
- 源色必须显式带
s分量：写成--base: hsl(200 70% 60%)✅；写成--base: #3498db或--base: rgb(52, 152, 219)❌（from无法解析） -
hsl(from var(--base) h calc(s + 10%) l)是合法写法，但注意：s是百分比值，calc()中所有参与运算的数都必须带% - 旧版 Safari（iOS 16.4 以下）完全忽略该语法，需加降级：
color: hsl(200, 80%, 60%); color: hsl(from var(--base) h calc(s + 10%) l);
为什么不能用 oklch(from ...) 或 lch(from ...) 提饱和度
oklch(from var(--c) l c h) 和 lch(from var(--c) l c h) 在当前所有稳定版浏览器中均不被识别——解析器遇到未知函数直接丢弃整条声明，控制台无报错，样式“消失”得无声无息。
- Chrome 111+ 开启
#css-relative-color-syntaxflag 后，仅支持color(from rgb(100 150 200) ...)这类硬编码值，不支持var(--c)引用 - PostCSS 插件（如
postcss-relative-color）可转译，但要求你在:root中写的--c必须是确定值（如rgb(100 150 200)），不能是另一个变量或表达式 - 即使转译成功，
oklch的c（色度）≠hsl的s（饱和度）：两者语义不同，调c不等于视觉上“更鲜艳”，尤其在蓝/紫区域偏差明显
真正可用的替代方案：color-mix() 模拟饱和度降低
如果源色是十六进制或 RGB，又想“降饱和”，color-mix() 是目前兼容性最好、行为最可控的选择。它不提取分量，而是通过混入灰阶来稀释色彩强度。
-
color-mix(in srgb, var(--primary) 80%, gray 20%)相当于把原色“冲淡”20%，视觉柔和，无色相偏移 - 注意
gray不是hsl(0, 0%, 50%)，而是设备灰阶，不同屏幕渲染略有差异，但对 UI 一致性影响极小 - 必须用
@supports (color-mix: normal)包裹，IE 和 Safari 15.4 以下需 fallback 到预设值：color: #5a6b8c; @supports (color-mix: normal) { color: color-mix(...); } - 别用
color-mix(in oklch, ...)—— oklch 空间虽更感知均匀，但color-mix(in oklch, ...)兼容性比 srgb 版本差得多，连部分 Chrome 120+ 都不支持
容易被忽略的关键约束：饱和度调整必须配合亮度重平衡
单纯调高 s 而不压低 l，极易导致颜色发虚、刺眼或在深色背景下泛光。这不是 bug，而是 HSL 模型的固有特性。
立即学习“前端免费学习笔记（深入）”；
-
hsl(210, 100%, 90%)的蓝在白色背景上像荧光笔，在深色背景上则边缘辉光；改成hsl(210, 90%, 55%)立刻稳重 - 用
clamp(30%, calc(s + 15%), 70%)限制范围比裸写calc(s + 15%)更安全，避免溢出后全灰（s: 0%） - 深色模式下，饱和度超过 50% 的蓝/紫系要同步降
l至 30%–45%，否则文字可读性骤降 - 伪元素（
::before）、SVGfill、第三方组件内联色——这些地方若没统一用hsl(var(--h), var(--s), var(--l))，你的--s变量再精准也毫无意义
