OKLCH的L值真正对应人眼感知亮度，而HSL的L仅为RGB极值平均、视觉亮度差异巨大；二者数值不可直接换算，oklch()的L必须带单位（如50%或0.5），且需配合@supports降级与色度约束才能保障一致性。
oklch() 的 L 值为什么不能直接套用 hsl() 的数值
HSL 的 L 是 RGB 三通道最大值与最小值的平均，纯数学构造，和人眼无关；OKLCH 的 L 是 OKLab 空间中的感知亮度坐标，经过 CIE 2002 色貌模型校正。实测：hsl(0, 100%, 50%)（纯红）CIE Y 亮度约 0.21，hsl(120, 100%, 50%)（纯绿）约 0.72，而oklch(0.5 0.32 0) 和 oklch(0.5 0.32 120) 在视觉明暗上才真正接近。
-
hsl(240, 100%, 50%)≈oklch(0.54 0.32 240)，不是oklch(0.5 0.32 240) - OKLCH 的 L 必须带单位：
oklch(50% 0.28 258.5)或oklch(0.5 0.28 258.5)，但后者仅 Chrome 112+/Firefox 121+/Safari 17.4+ 支持 - 写成
oklch(50 0.28 258.5)（缺%）会被所有浏览器静默忽略
色相环上做亮度统一时，oklch() 怎么避免“调 L 变灰”或“改 H 崩饱和”
问题本质是 HSL 在高饱和下色相过渡时，a/b 轴压缩导致中间段发灰；OKLCH 基于 OKLab，在全色相范围内 C 的扩展更平滑，但仍有边界陷阱。
- 禁用态不要动 L，只降 C：
oklch(0.62 0.28 258.5)→oklch(0.62 0.12 258.5)，避免文字在浅底上可读性断崖下跌 - 深色模式适配优先调 L，固定 C 和 H：
oklch(0.62 0.28 258.5)→oklch(0.38 0.28 258.5)，视觉过渡平滑，不发青也不发紫 - 色相插值跨 0°/360° 边界（如 350°→10°）会绕远，出现灰紫色带；必须手动拆段：
linear-gradient(oklch(0.7 0.25 350), oklch(0.7 0.25 0), oklch(0.7 0.25 10))
@supports 检测和 fallback 写法最容易失效的三个点
OKLCH 不支持时不是报错，而是整条声明被跳过——如果 fallback 写得不对，UI 就直接变黑、变透明或错色。
- 降级色必须写在
@supports块外部且上方：background-color: #2563eb;然后再包裹@supports (color: oklch(0% 0 0)) - 检测值必须带单位：
oklch(0% 0 0)，写成oklch(0 0 0)在 Safari 17.4+ 也返回 false - 别用
@supports not，安卓 WebView 存在解析 bug；也别用oklab()检测，目前所有主流浏览器都返回 false
调试 oklch() 时 DevTools 显示的永远不是真实值
Chrome/Firefox/Safari 的 computed 样式面板里，getComputedStyle(el).backgroundColor 返回的永远是降级后的 sRGB 十六进制值，不是你写的 oklch()。它不显示、不编辑、不验证 OKLCH 行为。
立即学习“前端免费学习笔记（深入）”；
- 真值只能靠肉眼比对：同一背景上放两块色块，一块用 OKLCH，一块用人工校准过的 sRGB fallback，看是否视觉一致
- JS 无法读出 OKLCH 原始参数，
getComputedStyle对 OKLCH 声明返回的仍是 sRGB - 建议日常使用 C ≤ 0.28，兼顾表现力与兼容性；H 值四舍五入到一位小数（如
258.5），避开 Safari 16.x 对多位小数的解析失败
hsl()、rgb() 或漏掉 @supports 降级，都会让感知均匀性瞬间归零。最常被忽略的，是把 OKLCH 当成“更好看的 HSL”来用，而不是当作一套需要整体迁移的色彩建模协议。 
