HSL 的 L 参数是 RGB 三通道最大值与最小值的算术平均，非感知亮度，导致相同 L 值下黄（~0.93 Y）比蓝（~0.07 Y）视觉亮十余倍；应改用 oklch() 的 L 或 WCAG 标准流程。
hsl() 的 L 参数不是感知亮度，而是数学平均值
你调 hsl(60, 100%, 50%)（黄）和 hsl(240, 100%, 50%)（蓝），明明 L 都是 50%，但黄看起来亮得多、蓝显得灰暗——这不是错觉，是 HSL 的 L 定义本身造成的。L 是 RGB 三通道最大值与最小值的算术平均：L = (max(R,G,B) + min(R,G,B)) / 2。这个公式对黄色（R=255, G=255, B=0）给出高 L，对蓝色（R=0, G=0, B=255）却给出相同 L，但人眼对黄光的敏感度远高于蓝光（视锥细胞响应峰值在 ~555nm）。结果就是：数值相等 ≠ 视觉亮度相等。
RGB 色域与人眼响应曲线不匹配
HSL 是 sRGB 空间内的重参数化，它没修正显示器发光特性与人眼感知之间的偏差。sRGB 中的 rgb(255, 255, 0)（黄）在 CIE Y（相对亮度）上约是 0.93，而 rgb(0, 0, 255)（蓝）仅约 0.07。这意味着：同一 L 值下，黄色实际发出的光通量是蓝色的 13 倍以上。浏览器照常渲染，但你的视觉系统忠实报告了这个差异。这不是 bug，是模型局限。
想真正统一视觉亮度？别用 hsl() 的 L
如果目标是“所有色相在相同明暗感下对比”，hsl() 的 L 就不该作为依据：
- WCAG 对比度计算必须用 sRGB → 线性光 → CIE Y 流程，
hsl()的L完全不可代入 - 深色模式适配时，直接降
hsl()的L会导致蓝变紫、红发粉——因为不同色相的亮度衰减非线性 - 替代方案：用
oklch()的L（如oklch(60% 0.3 60)和oklch(60% 0.3 240)），它的 L 是 OKLab 空间中的感知亮度坐标，跨色相一致性高得多 - 降级兼容写法：
color: oklch(60% 0.3 60); color: hsl(60, 100%, 50%);，现代浏览器用前者，旧浏览器回退到后者（接受亮度不一致）
调试时怎么快速验证亮度偏差
不要靠肉眼猜，用工具量化：
立即学习“前端免费学习笔记（深入）”；
- Chrome DevTools 的 Color Picker（长按颜色值）会显示 CIE LCH 和 sRGB Y 值，直接比对
L（OKLab）和Y（sRGB 相对亮度） - 在 CSS 中临时加
filter: brightness(0.8);看是否让蓝“追上”黄的明暗感——如果需要不同系数才能对齐，就证实了偏差存在 - 写个简易 JS 计算：输入 hex，输出对应 sRGB → linear → Y 值，比如
hexToY("#ffff00")返回 ~0.93，hexToY("#0000ff")返回 ~0.07
