用hsl()实现色相环需对色相值取模归零避免跳变，移动端用requestanimationframe节流渲染，color-mix()需指定色彩空间并降级处理，lch()比hsl()更符合人眼亮度感知，调色板应强制color-scheme: light确保高饱和显示。
怎么用 hsl() 实现可拖拽的色相环交互
直接用 hsl() 比 rgb() 更适合做调色板，因为色相（h）是 0–360 的线性值，拖动滑块或旋转角度能直连色相变化，不用换算十六进制或处理饱和度/明度耦合问题。
常见错误是把 hsl(360, 100%, 50%) 和 hsl(0, 100%, 50%) 当作不同颜色——其实它们完全一样，但用户拖到 360 时 JS 可能没归零，导致视觉跳变。
- 拖动时把色相值对 360 取模：
h = h % 360，再转成正数：h = (h + 360) % 360 - 不要用
input[type="range"]直接绑色相：默认 max=100，得手动设max="360"，否则拖满只到 100° - 移动端 touchmove 里别直接改
style.backgroundColor，先用requestAnimationFrame节流，不然 iOS Safari 渲染卡顿明显
CSS 自定义属性 + color-mix() 动态生成中间色阶时踩的坑
color-mix() 是 Chrome 111+ / Safari 16.4+ 才支持的真·渐变色生成器，比 JS 算 lch() 插值简单得多，但容易忽略它的默认混合空间和 fallback 行为。
典型现象：在 Firefox 里整个调色板变灰，或者混合结果偏暗——因为 color-mix(in srgb, red 50%, blue 50%) 在不支持浏览器里会直接退化成 red，而不是报错或忽略。
立即学习“前端免费学习笔记（深入）”；
- 必须显式声明色彩空间：
in lch比in srgb更符合人眼感知，尤其做明度均匀的色阶时 - 用
@supports (color-mix: in lch)包裹关键样式，不支持时降级用linear-gradient或预设几档 CSS 变量 -
color-mix()不接受变量名直接拼接，比如color-mix(in lch, var(--primary) 70%, white 30%)是合法的，但var(--mix-ratio)不能当权重数字用——CSS 还不支持变量参与计算
为什么用 lch() 做“亮度一致”的灰度切换总出问题
想让用户选个主色后，自动生成一组明度相同、仅色相/饱和度变化的配色？别碰 hsl() 的 l（lightness），它不是感知均匀的。真正靠谱的是 lch() 的 l（Lightness），取值 0–100，100 就是纯白，0 是纯黑，中间每+10 都约等于人眼感知的等亮度差。
错误做法：用 hsl(h, s, 60%) 固定 lightness 切换色相——黄色看着亮、蓝色看着暗，根本不是同一档亮度。
- Chrome DevTools 的颜色拾取器已支持
lch()显示，右键颜色值就能切，别手算 - JS 里转换需用
oklch()（更优）或lch()库，如culori，原生 CSS 不支持 JS 读取lch()计算值 - 导出设计稿时注意：Figma 支持
lch()输入但 Sketch 不支持，得提前转成srgb十六进制备用
prefers-color-scheme 和自定义色板联动时最常漏的一件事
很多人加了 @media (prefers-color-scheme: dark) 切主题色，但忘了：用户可能开了深色模式，却希望调色板本身保持明亮可读（比如设计师白天用深色系统，但调色板必须显示全色域）。
结果就是深色模式下，你的色相环变成灰蒙蒙一圈，饱和度被系统自动压低，甚至部分颜色不可见。
- 给调色板容器加
color-scheme: light，强制它无视系统偏好，保持亮底+高饱和渲染 - 如果真要响应深色模式，别只改背景，重点调
color和border-color，确保文字对比度 ≥ 4.5:1（可用contrast()函数辅助） - 测试时别只看 macOS 系统设置，Windows 的“深色应用模式”和 Android 的“增强深色”行为不一致，得真机点开系统设置试
调色板工具最难的从来不是画个圆环或生成十六进制，而是让每个颜色在各种设备、系统、缩放比、DPI 下都稳定可辨——尤其是饱和度和明度的微小偏移，在 200% 缩放的 Surface 屏上会被放大三倍。
