RGB转HSL需先归一化并处理max===min边界，否则H/S/L全错或NaN；HSL转RGB须归一化H并处理s===0；原生API不提供转换，精度损失不可避免。
RGB 转 HSL 的核心逻辑和常见偏差
直接用 rgbToHsl 函数时，如果没归一化 RGB 值（即没除以 255），H、S、L 会全错；更隐蔽的问题是：当 max === min（如纯灰阶色）时，h 应设为 0，但不少手写实现漏掉这个判断，导致返回 NaN 或负值。
正确做法是先将 r、g、b 映射到 [0, 1] 区间，再按标准公式计算：
function rgbToHsl(r, g, b) {
r /= 255; g /= 255; b /= 255;
const max = Math.max(r, g, b);
const min = Math.min(r, g, b);
let h, s, l = (max + min) / 2;
if (max === min) {
h = s = 0; // achromatic
} else {
const d = max - min;
s = l > 0.5 ? d / (2 - max - min) : d / (max + min);
switch (max) {
case r: h = (g - b) / d + (g < b ? 6 : 0); break;
case g: h = (b - r) / d + 2; break;
case b: h = (r - g) / d + 4; break;
}
h /= 6;
}
return { h: Math.round(h 360), s: Math.round(s 100), l: Math.round(l * 100) };
}
HSL 转 RGB 容易忽略的边界处理
hslToRgb 最常出错的地方是：没把 h 归一化到 [0, 1)，或没对 h 做模 360 处理——比如传入 h = 400 就直接崩。另外，当 s === 0 时，应直接返回灰阶值，跳过六段分段计算，否则浮点误差可能让结果偏离预期。
关键步骤包括：
立即学习“Java免费学习笔记（深入）”；
- 强制
h = ((h % 360) + 360) % 360，再除以 360 得h∈ [0,1) -
s和l必须先除以 100，转为 [0,1] 区间 - 用
h * 6确定色相段（0–5），再算出对应区间的p、q、t
function hslToRgb(h, s, l) {
h = ((h % 360) + 360) % 360 / 360;
s /= 100;
l /= 100;
if (s === 0) {
const v = Math.round(l * 255);
return { r: v, g: v, b: v };
}
const q = l < 0.5 ? l (1 + s) : l + s - l s;
const p = 2 * l - q;
const hue2rgb = (p, q, t) => {
if (t < 0) t += 1;
if (t > 1) t -= 1;
if (t < 1/6) return p + (q - p) 6 t;
if (t < 1/2) return q;
if (t < 2/3) return p + (q - p) (2/3 - t) 6;
return p;
};
const r = Math.round(hue2rgb(p, q, h + 1/3) 255);
const g = Math.round(hue2rgb(p, q, h) 255);
const b = Math.round(hue2rgb(p, q, h - 1/3) * 255);
return { r, g, b };
}
CSS color() 函数和原生 API 不解决互转问题
别指望 color()、CSS.supports('color', 'hsl(0 100% 50%)') 或 window.getComputedStyle 能帮你做数值转换。它们只负责解析/序列化字符串，不提供底层算法。比如 getComputedStyle(el).backgroundColor 返回 "rgb(255, 0, 0)"，你仍得自己切字符串、转数字、再调用 rgbToHsl —— 没捷径。
真正省事的方式只有两个：
- 用成熟库如
chroma.js（chroma(rgb).hsl()） - 自己封装上述两个函数，并加一层输入校验（如
h超出 [0,360] 自动截断）
精度损失和整数截断的实际影响
RGB 是离散整数（0–255），HSL 是连续空间（尤其 h 理论上无限精细），所以 rgb → hsl → rgb 往往回不到原值。例如 rgb(127, 128, 129) 转成 HSL 后再转回，大概率变成 (127, 128, 128) 或类似。这不是 bug，是量化误差。
如果你在做颜色调节 UI（比如滑块实时更新预览），建议：
- 内部始终用浮点 HSL 运算（不四舍五入到整数）
- 仅在显示或输出时调用
Math.round() - 避免链式多次互转：先存原始 RGB，每次调节都基于它重新计算，而不是“上次 HSL → 新 HSL → RGB”
最麻烦的其实是深灰（l ≈ 0）和亮白（l ≈ 100）附近，s 的微小变化会导致 RGB 值剧烈抖动，这时候人眼几乎看不出区别，但数值上可能差好几格——别花时间调这个。
