不能用 hsl() 函数旋转色相生成配色板，因其不支持动态偏移；应使用 hsl(from <color> calc(h + N) s l) 语法或 JavaScript 转换。
不能用 hsl() 函数“旋转”色相生成配色板——它不支持动态色相偏移，只能固定颜色；真正能做这件事的是 hsl(from <color> calc(h + N) s l) 语法，或 JavaScript 配合 RGB→HSL 转换。
为什么 hsl(calc(var(--hue) + 180), s, l) 大概率失效
这个写法在绝大多数浏览器里不会按预期工作，常见问题包括：
-
calc()中单位不匹配：比如var(--hue)是纯数字（如240），但你加了带单位的180deg，CSS 解析直接报错 - 旧版浏览器（Chrome ≤125 / Firefox ≤124）根本不支持
calc()在hsl()第一个参数里的运行时求值，静默退为透明或继承色 - 结果超出 0–360 范围（如
355 + 30 = 385）时，部分引擎截断而非取模，导致颜色突变成灰/黑 - 即使数值合法，
hsl()本身不提取已有颜色的 HSL 分量——你得先知道原始色的h值，而 CSS 没有内置方法读取color的色相
正确做法：用 hsl(from <color> ...) 动态计算互补色、类似色
这是目前唯一无需 JS、纯 CSS 实现“基于原色旋转生成配色”的标准方案，要求环境支持：Chrome 111+、Safari 16.4+、Firefox 115+。
- 互补色：直接写
hsl(from var(--base) calc(h + 180) s l)，h + 180自动模 360（350 + 180 → 170），无需手写% 360 - 类似色（±30°）：用
hsl(from var(--base) calc(h + 30) s l)和hsl(from var(--base) calc(h - 30) s l) - 三色组（+120°/+240°）：同理，
calc(h + 120)、calc(h + 240) - 注意：
s和l是原样复用的，若原始色明度极低（如l: 10%），互补色也会很暗——必要时可显式调整，例如calc(l + 20)或max(30%, l)（需浏览器支持max()）
降级方案：JS 实时转换 HEX → HSL 再生成配色
当必须兼容旧浏览器，或需要更灵活控制（比如拖拽色环、实时预览），JS 是唯一可靠路径：
立即学习“前端免费学习笔记（深入）”；
- 用正则或
parseInt()提取#4a90e2的 R/G/B 分量，套用标准公式转成 HSL 浮点值 - 对
h做运算后，先执行(h + 360) % 360再四舍五入，避免边界跳变（如359.6 → 0不应变成360） - 饱和度和明度建议截断到
20%–90%区间：Math.min(Math.max(s, 20), 90)，防止生成发灰或刺眼的“类似色” - 导出时用
navigator.clipboard.writeText()，不支持则降级为document.execCommand('copy')（已废弃但仍有 fallback 效果）
容易被忽略的视觉陷阱
即使语法全对、计算无误，配色仍可能翻车：
- HSL 的
l（lightness）不是感知均匀的——同样设l: 60%，黄色看着亮、蓝色看着暗。要做“亮度一致”的配色，得用lch()的L值，但兼容性更差（仅 Chrome 111+/Safari 16.4+） - 移动端
input[type="range"]默认max="100"，绑色相必须显式设max="360"，否则拖满只到 100° - 旧版 Safari 不支持
hsl(200, 70%, 55%)中的百分号带小数，必须四舍五入为整数：hsl(200, 70%, 55%)可以，但hsl(200, 70%, 55.3%)会失败 -
color-mix()看似能插值，但它默认在srgb空间混合，人眼感知不均；要用in lch才靠谱，且必须@supports降级
