oklch()是设计系统唯一能实现L、C、H三通道真正解耦的颜色函数，调L不偏色、调C不变亮、调H不失饱和；其L基于CIE 2002感知模型校正，与hsl()的数学平均L本质不同，数值不可直接套用。
现代CSS架构中推荐以 oklch() 作为设计系统基准，不是因为它“新潮”或“语法漂亮”，而是它唯一能保证 L（明度）、C（色度）、H（色相）三者真正解耦——调 L 不偏色、调 C 不变亮、调 H 不失饱和。其他颜色空间做不到这点，HSL 尤其危险。
为什么 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(54% 0.32 0) 和 oklch(54% 0.32 120) 才真正在人眼看来“一样亮”。
-
hsl(240, 100%, 50%)≈oklch(54% 0.32 240)，不是oklch(50% 0.32 240) - 品牌色迁移必须用工具重采样（如 colorjs.io），不能手动换函数名
- DevTools 的 computed 样式永远只显示降级后的 sRGB 十六进制值，不反映真实
oklch()行为
@supports 降级结构写错，整条规则就静默消失
oklch() 不支持时浏览器不会报错，也不会 fallback，而是整条声明被跳过。如果降级色写在 @supports 块内部，或检测值缺单位，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—— 安卓 WebView 有解析 bug，会丢弃整块规则 - 别用
oklab()检测 —— 所有主流浏览器目前都返回 false
渐变与动画中色相跨 0° 边界必须手动拆段
CSS 对 oklch() 渐变不做色相短弧插值。写 oklch(0.7 0.25 350) → oklch(0.7 0.25 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)) - 所有节点必须统一用
oklch()，混用hsl()或rgb()会让整条渐变 fallback 到 sRGB 插值，前功尽弃 - 悬停/过渡动画同理：哪怕
--primary是oklch()，只要 hover 状态用了其他色彩空间，中间帧必然发灰
最常被忽略的不是“怎么写”，而是单位细节和 fallback 顺序——错一个 %，整行失效；降级色位置错一格，旧环境连基础色都看不到。
