oklab() 和 oklch() 是同一感知模型下的两种坐标表达：oklab(L a b) 为直角坐标，适合计算但 CSS 中不推荐；oklch(L C H) 为极坐标，是 CSS 中真正可用的语义化颜色函数，L需带%或为0–1小数，C无单位，H为纯数字，混用二者会导致声明失效。
oklab() 和 oklch() 不是“两个可互换的颜色函数”，而是同一感知模型（Oklab）下的两种坐标表达，用途、参数结构、适用场景完全不同。
oklab(L a b) 是直角坐标，适合计算但不适合直接写 CSS
它把颜色表示为三个正交分量：L（亮度）、a（红绿轴偏移）、b（黄蓝轴偏移），全为无量纲小数（如 oklab(0.6 -0.12 0.08)）。
浏览器支持它，但不推荐用于样式声明，原因包括：
-
oklab()没有直观色相概念——改a或b值时，人眼无法预判色调变化，容易导致发灰、偏紫等数学退化现象 - 在
linear-gradient()或color-mix()中，即使两端都用oklab()，浏览器仍默认按 sRGB 插值，不触发 OKLab 插值逻辑 - JS 中做插值、对比度校验、无障碍分析时很可靠；但人工维护 CSS 时极易出错，比如误把
a/b当成 HSL 的S/L直接调
oklch(L C H) 是极坐标，才是 CSS 中真正可用的语义化颜色函数
oklch() 把 Oklab 转成人类可读的三元组：L（感知亮度）、C（彩度）、H（色相角），单位严格：L 必须带 % 或为 0–1 小数，C 是无单位小数（如 0.28），H 是纯数字（258.5，不能加 deg）。
- 调
L真的只改明暗：深色模式下从oklch(62% 0.28 258.5)→oklch(38% 0.28 258.5)，蓝色不会发紫也不会变灰 - 调
C真的只改鲜艳度：禁用态可设为oklch(62% 0.12 258.5)，保色相、保可读性 -
H是 0–360° 色环映射，调试时一眼看出是否对齐色相；但注意：浏览器不做跨 0°/360° 的短弧优化，350° → 10°必须手动拆成两段
混用二者会导致静默失效或插值降级
哪怕只是在一个 linear-gradient() 里混写 oklab(0.6 -0.12 0.08) 和 oklch(60% 0.28 258.5)，整条渐变声明会被浏览器直接忽略——不是 fallback 到 sRGB，而是整个规则块失效。
- CSS 自定义属性中混用（如
--primary: oklab(...); --hover: oklch(...);），transition会强制走 sRGB 插值，“先灰一下再显色” -
@supports (color: oklab(0 0 0))在所有主流浏览器中都返回false，检测必须用oklch(0% 0 0)，且值必须带单位 - 降级结构必须是：先写 fallback（如
background-color: #2563eb;），再写@supports块，顺序颠倒或放在块内会导致某些安卓 WebView 完全跳过
@supports 值不带单位、混用函数——这些都不是“警告”，而是让颜色凭空消失的硬性失败。 
