直接用hsl(var(--h),var(--s),var(--l))配色可行，但必须拆解H/S/L三级变量并控制联动；禁用硬编码--primary，色相偏移用calc()而非JS取模，亮度饱和度不可线性缩放，hsl(from)是复杂配色最优解。
直接用 hsl(var(--h), var(--s), var(--l)) 做逻辑配色是可行的，但必须拆解变量、控制分量联动关系——否则颜色会失控或语义崩坏。
变量必须拆到 H/S/L 三级，不能只存一个 --primary
硬编码 --primary: hsl(210, 85%, 55%) 看似省事，但后续想调深一点或换紫，就得手动拆解再重写。JS 修改时也拿不到单个分量，无法做 calc(var(--l) - 10%) 这类运算。
- 正确做法：在
:root中分别定义--h、--s、--l，再组合出--color - 错误写法：
--primary: hsl(210, 85%, 55%)→ 后续所有派生色都得靠字符串拼接或 JS 解析，不可维护 - 注意：饱和度和亮度必须带
%单位（85%），色相不用（210）；写成0.85或85（无%）会导致整条声明被浏览器忽略
色相偏移必须用 calc()，别手动算模 360
想从主色生成互补色（+180°）或三色组（±120°），直接写 calc(var(--h) + 180) 就行。浏览器内部自动对色相取模，hsl(390, ...) 和 hsl(30, ...) 渲染结果一致。
- 不要在 JS 里做
(hue + 180) % 360→ JS 的负数取模行为和 CSS 不一致（比如-10 % 360得-10，而 CSS 期望的是350） - 避免手写
hsl(30, ...)替代calc(var(--h) + 180)→ 会跳过色环过渡段，配色突兀 -
hsl(from var(--base) calc(h + 30) s l)更稳妥，尤其当基础色来自currentcolor或动态计算时
亮度和饱和度不能独立线性缩放
把 --s 从 85% 直接 ×0.5 得 42.5%，视觉上不是“减半鲜艳”，而是可能发灰；同理，--l 加 10% 在暗色区（20%→30%）比亮色区（80%→90%）影响大得多。
立即学习“前端免费学习笔记（深入）”；
- 禁用态慎用
saturation: calc(var(--s) * 0.3)→ 原--s若为 20%，结果 6% 几乎不可见；建议固定设20%或10% - 悬停变亮优先用
lightness: calc(var(--l) + 10%)，而非硬写65%→ 能适配不同基础亮度的主题 - 深色模式文字推荐
lightness: 20%+saturation: 5%，而不是按比例降 L/S —— 防对比度跌破 WCAG 4.5:1
hsl(from ...) 是复杂逻辑配色的真正解法
当你需要“只改一个分量，其余继承”时，hsl(from) 比一堆 var() + calc() 更可靠，且不依赖变量是否已定义。
- 例如：
background-color: hsl(from var(--primary) calc(h + 20) s l)→ 只动色相，S/L 自动复用 - 比
hsl(calc(var(--h) + 20), var(--s), var(--l))少一层变量依赖，也不怕--s或--l未定义时整个函数失效 - 支持
hsl(from #2563eb h s l / 0.8)直接基于 HEX 值派生，无需先转 HSL 存变量 - 注意：
hsl(from)在 Firefox 中需前缀-moz-hsl(from ...)（截至 2026 年 7 月）
真正难的不是写对语法，而是判断哪个分量该动、动多少——色相偏移要守色环逻辑，亮度调整得盯住可访问性阈值，饱和度只能当呼吸感微调。变量只是工具，配色逻辑才是核心。
