色相差值需模360运算，避免手动截断导致过渡突兀；HSL的S/L非线性，配色应依视觉权重动态补偿；hsl(from)语法支持分量继承，提升可维护性。
色相差值计算不是简单加减，而是模360角度运算
直接对hue值做+20或-30看似合理，但忽略色相环的循环性。比如主色是hsl(350, 80%, 60%)（近红），想取相邻色+40°，写成hsl(390, 80%, 60%)浏览器会自动归约为hsl(30, 80%, 60%)（橙），这是正确行为；但若手动算错成hsl(40, 80%, 60%)，就跳过了10°的红色过渡段，配色会突兀。
常见错误现象：在CSS变量中用calc()做色相偏移时写calc(var(--hue) + 40)没问题，但若原始--hue是负数（如--hue: -10），calc(-10 + 40)得30°是对的；而calc(350 + 40)得390°也合法——浏览器内部处理就是模360，无需你手动% 360。
- 色相支持任意整数，
hsl(720, 50%, 50%)等价于hsl(0, 50%, 50%) - 避免在JS里用
%运算模拟：JS的-10 % 360得-10，而CSS期望的是350，结果不一致 - 调试时用DevTools颜色拾取器看实时HSL值，比肉眼判断更可靠
配色比例依赖饱和度与亮度的非线性区间
HSL的saturation和lightness不是均匀感知的。把saturation从30%调到60%，视觉上“纯度提升”远不如从60%到90%明显；而lightness在20%–40%区间微调5%，比在50%–70%区间同样5%变化更影响可读性。
这意味着按固定百分比生成配色比例（如“主色S=80%，辅助色S=60%，强调色S=40%”）容易失衡。真正稳定的策略是：
立即学习“前端免费学习笔记（深入）”；
- 深色背景文字：优先压低
lightness至12%–20%，同时把saturation控制在0%–10%保中性，而非机械减20% - 悬停态变亮：用
calc(var(--light) + 10%)比固定设60%更适配不同基础亮度 - 禁用态降饱和：设
saturation: 20%比calc(var(--sat) * 0.4)更可控，避免原饱和度低时算出0%直接变灰
hsl(from ...)语法让相对配色真正可计算
CSS新语法hsl(from <color> h s l / a)</color>才是解决复杂配色比例的底层能力。它允许你基于一个基准色，只改其中一两个分量，其余自动继承。比如：
button { background-color: hsl(210 85% 55%); }
button:hover { background-color: hsl(from var(--primary) 230 s l); }
button:disabled { background-color: hsl(from var(--primary) h s 30%); }这里button:hover只动了色相（+20°），饱和度和亮度完全复用基准色；:disabled则只压亮度，其他不变。不用再拆解变量、拼接var()，也不用担心calc()兼容性。
注意点：
-
from后必须是有效颜色值，不能是未定义的CSS变量 - 目前Chrome 111+、Firefox 115+、Safari 16.4+支持，旧版Safari需回退到传统
hsl()写法 - 无法用
from引用另一个hsl(from ...)嵌套，链式推导要靠JS或构建时处理
色相环不是RGB色轮，跨象限偏移需警惕视觉断裂
RGB色轮里红→绿是顺滑过渡，但HSL色相环上0°（红）到120°（绿）之间经过60°（黄）、90°（黄绿），逻辑连续；而180°（青）到240°（蓝）之间是210°（蓝绿）。问题在于：人眼对0°–60°（暖色）和180°–240°（冷色）的敏感度不同，同样±15°偏移，在暖区可能只是“偏橙的红”，在冷区却变成“泛紫的蓝”，破坏配色一致性。
实际做法：
- 同一组配色尽量限制在±30°以内，比如主色
210°，辅助色用195°或225°，别跳到180°或240° - 需要跨象限（如红→蓝）时，宁可用
saturation或lightness制造层次，而不是硬拉色相 - 色觉障碍用户可能混淆
180°和200°，搭配时检查WCAG对比度，别只依赖色相区分
真正难的不是算出数值，而是理解HSL每个分量在真实屏幕上的渲染权重——色相决定方向，饱和度决定“存在感”，亮度决定“是否看得清”。随便改一个，其他两个就得动态补偿。
