OKLCH 不是 HSL 的升级版而是独立方案，其 L 值基于感知亮度不可直接套用 HSL 数值；需注意单位、fallback 顺序、渐变色相断层及禁用态仅降 C 等关键细节。
OKLCH 不是 HSL 的“升级版”，而是解决不同问题的独立方案——如果你需要调亮度时颜色不偏移、调饱和度时不改变明暗、调色相时不损失鲜艳度，那 OKLCH 是目前唯一能稳定做到的 CSS 颜色函数。
oklch() 的 L 值为什么不能直接套用 hsl() 的数值
HSL 的 lightness 是 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, 70%, 50%)直接改成oklch(50% 0.28 240)，结果蓝变灰紫 - 漏写
%单位，如oklch(50 0.28 240)—— 所有浏览器静默忽略整条声明 - 误用小数形式
oklch(0.5 0.28 240)：仅 Chrome 112+/Firefox 121+/Safari 17.4+ 支持，旧版全失效
@supports 检测和 fallback 写法最容易失效的三个点
OKLCH 不支持时不会报错，而是整条声明被跳过。如果降级结构写错，UI 可能直接变黑、透明或错色。
立即学习“前端免费学习笔记（深入）”；
- 降级色必须写在
@supports块外部且上方：background-color: #2563eb;→ 再跟@supports (color: oklch(0% 0 0)) { ... } - 检测值必须带单位：
@supports (color: oklch(0% 0 0))✅，@supports (color: oklch(0 0 0))❌（Safari/Chrome/Firefox 全部返回 false） - 绝对不要用
@supports not或oklab()检测：安卓 WebView 对@supports not有解析 bug；所有主流浏览器对oklab()检测均返回 false
linear-gradient 中色相跨 0° 边界时出现灰紫色带
CSS 对 oklch() 渐变不做色相短弧插值。写 oklch(0.7 0.25 350) → oklch(0.7 0.25 10)，浏览器按数值线性插值：350 → 360 → 10，中间段 H=0° 附近 C 被强制压缩，导致灰紫色断层。
- 色相差超过 180° 时，必须手动拆成两段：
linear-gradient(oklch(0.7 0.25 350), oklch(0.7 0.25 0), oklch(0.7 0.25 10)) - 所有节点必须统一用
oklch()；混用rgb()或hsl()会导致整条渐变被丢弃，背景可能变透明 - 禁用态不要动
L，只降C：oklch(0.62 0.28 258.5) → oklch(0.62 0.12 258.5)，避免文字在浅底上可读性断崖下跌
最常被忽略的不是“该不该用”，而是单位细节和 fallback 顺序：错一个 %，整行失效；降级位置错一层，UI 在旧设备上直接不可用。DevTools 的 computed 样式里永远只显示降级后的 sRGB 十六进制值，看不到真实 OKLCH 行为——真值只能靠肉眼比对 + 控制 C ≤ 0.28 来规避色域漂移风险。
