rgbToHsl 函数必须先将 RGB 归一化到 [0,1] 区间，再计算 max/min 和亮度 L；灰色判定需严格用 max === min 判断，避免浮点误差导致饱和度异常。
rgbToHsl 函数怎么写才不翻车
直接用 rgbToHsl 转换时，最常出错的是没做归一化——RGB 值必须先除以 255 转成 [0, 1] 区间，否则后续的 max/min 计算和公式分母会全乱。比如 {red: 255, green: 0, blue: 0} 若跳过归一化，L = (255 + 0) / 2 = 127.5，但 HSL 的亮度定义域是 [0, 1]，后续饱和度、色相计算全部崩坏。
- 务必先做
r = red / 255、g = green / 255、b = blue / 255 - 注意浮点精度：用
Math.min(r, g, b)而非手写三元嵌套，避免 JS 中NaN或比较异常 - 灰色判定要严格：
if (max === min)才设s = 0；若用Math.abs(max - min) 更稳妥（尤其处理 float 计算误差）
HSL 色相 H 计算为什么总偏 180°
问题出在色相公式的分支逻辑和单位换算上。原始公式中：if R === max 时 H = (G - B) / (max - min)，结果是弧度比值，**必须乘以 60 再归一到 [0, 360)**，且负值要加 360。漏掉任一环节都会导致色相错位——比如红色本该是 0°，却算成 -120° 或 240°。
- 别省略
H *= 60步骤；JS 中可写H = ((G - B) / delta) * 60 - 所有分支后统一做
H = H ，再Math.round(H)防止小数漂移 - 注意：HSL 的 H 是角度制（0–360），不是弧度；CSS 中
hsl(0, ...)和hsl(360, ...)等价，但中间值必须落在 [0, 360) 闭开区间
浏览器里其实不用手写转换函数
CSS 引擎原生支持 RGB/HSL 互转，只要颜色值是合法 CSS 颜色，就能用 getComputedStyle 或 CSSOM 提取并重铸。比如把 #ff6b6b 转成 HSL，不必解析十六进制再套公式：
const el = document.createElement('div');
el.style.color = '#ff6b6b';
document.body.appendChild(el);
const computed = getComputedStyle(el).color; // 返回 rgb(
255, 107, 107)
// 再用 CSS.supports('color', 'hsl(0, 0%, 0%)') 确认支持后，直接赋值 hsl()
el.style.color = 'hsl(0, 50%, 72%)';
document.body.removeChild(el);
- 适用于运行时动态调色（如主题切换）、调试验证，比手写算法更可靠
- 局限：无法获取中间计算过程（如 delta、L 值），也不适合服务端或无 DOM 环境
- 注意：
getComputedStyle返回的是rgb()或rgba()字符串，需正则提取数字再转 HSL——这步仍需手写，但只用于调试，不参与生产逻辑
Stylus/Sass 里的转换为何和 JS 结果不一致
因为预处理器默认对 HSL 分量做「感知校正」：Stylus 的 hsl(#ff6b6b) 返回的是视觉等距 HSL（类似 lch 感知空间映射），而 JS 手写公式实现的是标准几何 HSL（基于 RGB 立方体投影）。两者在饱和度高、亮度极端时差异明显——比如 #ff0000 在 Stylus 中可能返回 hsl(0, 100%, 50%)，但 JS 公式算出来可能是 hsl(0, 100%, 50.2%)（因浮点舍入+亮度定义微差）。
- 不要跨工具比对 HSL 数值是否“完全相等”，重点看渲染效果是否一致
- 若需精确复现 Stylus 行为，查其源码：Stylus 使用的是
chroma-js或类似库的变体，而非纯数学公式 - 生产中建议统一用一种工具链转换（例如全用 PostCSS 插件
postcss-color-function），避免混用导致主题色偏移
实际项目里，最易被忽略的是：HSL 的 L（亮度）不是线性明度，而是 RGB 值的算术平均，对深色/浅色感知不均。比如 hsl(0, 100%, 20%) 看起来比 hsl(0, 100%, 80%) 暗得多，但数值上只是 20→80 的简单变化——调色时得靠人眼校验，不能只信数字。
