rgbtohsl不准主因是未归一化：rgb值须先除以255缩放到[0,1]，否则max/min错、l超域、s/h全崩；需用math.min(r,g,b)求极值，灰色判定用max===min或加容差。
rgbToHsl 函数总算不准？先检查归一化这一步
绝大多数手写 rgbToHsl 出错，不是公式记错，而是漏掉了最关键的预处理：RGB 值必须先除以 255，缩放到 [0, 1] 区间。跳过这步，max/min 计算全乱，亮度 L 算出来是 127.5，但 HSL 的 L 定义域是 [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)
H 色相算出来偏 180°？单位和符号没闭环
HSL 的色相 H 是角度制（0–360°），不是弧度，也不是无量纲比值。原始公式中 (G - B) / (max - min) 是一个比值，必须乘以 60 再归一到 [0, 360)——漏掉 * 60 或负值没加 360，红色就会从 0° 变成 -120° 或 240°。
- 每个分支后统一做
H = ((G - B) / delta) * 60（红分支）、((B - R) / delta) * 60 + 120（绿分支）等 - 所有分支结束后必须补上：
H = H ，再 <code>Math.round(H)防止小数漂移 - CSS 中
hsl(0, ...)和hsl(360, ...)等价，但中间值必须落在[0, 360)闭开区间
不用手写转换？DOM + getComputedStyle 更快更稳
浏览器原生支持 RGB/HSL 互转，只要颜色是合法 CSS 颜色值，就完全没必要手撕公式。用 getComputedStyle 提取计算后颜色，再重赋值 hsl()，既绕过精度陷阱，又兼容各种 CSS 颜色变体（如 rebeccapurple、oklch(50% 0.2 270)）。
- 示例流程：
el.style.color = '#ff6b6b'→getComputedStyle(el).color返回"rgb(255, 107, 107)"→ 正则提取数字 → 构造hsl(...)字符串 - 适用场景：运行时主题切换、UI 调试、颜色采样，比手写函数更可靠
- 局限：无法获取中间变量（如
delta或L值）；服务端或无 DOM 环境不可用
Stylus/Sass 的 hsl() 和 JS 结果不一致？不是 bug，是空间不同
Stylus 的 hsl(#ff6b6b) 返回的不是标准几何 HSL，而是做了「感知校正」的视觉等距 HSL（类似 LCH 空间映射）；而 JS 手写公式实现的是基于 RGB 立方体投影的标准 HSL。两者数值差异是设计使然，不是计算错误。
立即学习“前端免费学习笔记（深入）”；
- Stylus/Sass 更适合设计稿直出、人眼调色；JS 公式更适合算法控制、精确插值
- 若需跨平台一致，建议统一用
OKLCH或LAB空间做中间桥接（需 polyfill） - 日常开发中，只要明确使用场景，不必强行对齐——CSS 引擎渲染最终看的是解析后的色值，不是中间表示
真正难的从来不是公式本身，而是归一化、单位、容差、空间语义这些藏在括号里的细节。写一次 rgbToHsl 容易，让它在所有边界色（纯黑、纯白、灰色、溢出值）下都稳定输出，才见真章。
