OKLCH的L值不能直接套用HSL数值，因其语义本质不同：HSL的L是RGB极值平均的数学值，OKLCH的L是经CIE 2002校正的感知亮度坐标；实测同L=50%下红绿亮度差三倍，而OKLCH同L才视觉等亮；且OKLCH的L必须带单位（如50%或0.5），缺单位则整条声明静默失效。
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)（缺%）会被所有浏览器静默忽略
@supports 检测和 fallback 写法最容易失效的三个点
OKLCH 不支持时不是报错，而是整条声明被跳过——如果 fallback 写得不对，UI 就直接变黑、变透明或错色。
- 降级色必须写在
@supports块外部且上方：background-color: #2563eb;，再包裹@supports (color: oklch(0% 0 0)) - 检测值必须带单位：
@supports (color: oklch(0% 0 0))✅，@supports (color: oklch(0 0 0))❌（Safari 17.4+ 也返回 false） - 别用
@supports not，安卓 WebView 存在解析 bug；也别用oklab()检测，目前所有主流浏览器都返回 false
色相插值跨 0°/360° 边界时出现灰紫色带
CSS 对 oklch() 渐变不做色相短弧优化，oklch(0.7 0.25 350) → oklch(0.7 0.25 10) 会从 350° 经过 0°、10° 插值，数值上是 350→360→10，导致中间段色度被强制拉低。
- 色相差超过 180° 时，必须手动拆成两段：
linear-gradient(oklch(0.7 0.25 350), oklch(0.7 0.25 0), oklch(0.7 0.25 10)) - 禁用态不要动
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)
调试 oklch() 时 DevTools 显示不可信
Chrome DevTools 在 computed 样式里永远只显示降级后的 sRGB 十六进制值，看不到真实 OKLCH 行为。真值只能靠肉眼比对 + 限制 C ≤ 0.28 控制色域漂移风险。
立即学习“前端免费学习笔记（深入）”；
- 用 JS 验证：
getComputedStyle(el).backgroundColor返回的永远是 sRGB 值，不是 OKLCH - 写
oklch()时 H 小数位建议 ≤1（如258.5），旧版 Safari 对258.5432解析异常 -
oklch()参数写错一个单位，整条声明就静默失效 —— 浏览器不报错、不 fallback，直接跳过
hsl() 的 L 值根本不可信。它要求你放弃“套数值”习惯，转而理解 L/C/H 各自对应的感知维度，并严格约束写法和降级结构。 
