OKLCH 与 LCH 底层色彩空间不同：LCH 基于 CIELAB（蓝紫区感知压缩），OKLCH 基于 OKLab（L 通道更符合人眼明暗响应，色域更大且更线性）；参数单位、取值规则、@supports 写法及渐变动画处理均需严格区分。
OKLCH 不是 LCH 的升级补丁，而是底层色彩空间不同导致的感知行为差异——用错一个就可能让深色模式按钮在 Safari 上变灰块。
oklch() 和 lch() 的底层空间完全不同
lch() 基于 CIELAB 空间，OKLCH 基于 OKLab。关键区别在于：CIELAB 在蓝紫区域存在感知压缩，调高 C 值时人眼觉得“没变亮”，而 OKLab 的 L 通道更贴近人眼对明暗的真实响应，尤其在 20%–60% 明度区间。
- 同一组参数
lch(50% 80 270)和oklch(50% 0.8 270)渲染出的蓝，前者看起来偏暗、发闷；后者更通透，饱和感更真实 - OKLab 的色域略大，尤其在高饱和青绿区域（如 P3 广色域显示器下），
oklch(70% 0.45 140)能表达出lch(70% 85 140)达不到的鲜活感 - 做深色模式 UI 色阶时，
oklch(30% 0.15 240)→oklch(40% 0.15 240)的亮度变化比lch()更线性，不容易出现“跳灰”
参数单位和取值规则不能混用
两者都要求 L 用 % 或小数（0–1），H 是 0–360 数值不带单位，但 C 的含义和写法有本质区别：
-
lch()的 C 是色度值，范围依赖色调和色域，在 sRGB 下常见 0–130，可直接写整数如lch(50% 95 270) -
oklch()的 C 是归一化色度，必须为无单位小数（0–0.5 左右较安全），写成oklch(50% 95 270)或oklch(50% 95% 270)都会静默失效 - 旧版 Safari（17.4 之前）和部分安卓 WebView 对
oklch(0.5 0.28 258.5)（L 用小数）支持不稳定，推荐统一用%：oklch(50% 0.28 258.5)
@supports 检测和降级逻辑必须分开写
只靠两行颜色声明 fallback，某些安卓 WebView 会直接跳过整个规则块——这不是 bug，是解析器对未识别函数的保守策略。
立即学习“前端免费学习笔记（深入）”；
- 错误写法：
color: #3b82f6; color: oklch(54% 0.32 240);—— 在部分环境里第二条被忽略，且不报错 - 正确结构必须把降级色写在
@supports外部上方：button { color: #3b82f6; }@supports (color: oklch(0% 0 0)) { button { color: oklch(54% 0.32 240); } } - 检测值必须带单位：
@supports (color: oklch(0% 0 0))✅，@supports (color: oklch(0 0 0))❌ - 别用
oklab()做检测——所有主流浏览器目前都返回false
渐变和动画中色相跨越要手动拆分
CSS 对 oklch() 渐变不做短弧优化，oklch(0.7 0.25 350) → oklch(0.7 0.25 10) 会从 350° 经 360°→0°→10° 插值，中间段 C 被强制压低，出现难看的灰紫色断层。
- 色相差 ≤180° 可直连：
oklch(0.7 0.25 20) 0%, oklch(0.7 0.25 190) 100% - 色相差 >180° 必须拆成两段：
oklch(0.7 0.25 350) 0%, oklch(0.7 0.25 0) 50%, oklch(0.7 0.25 10) 100% - 动画中若用 CSS 自定义属性控制色相，
--h: 350; --h: 10;仍会走长弧，需配合 JS 或color-mix()替代
OKLCH 的优势不是“更炫”，而是当你要精确控制深色模式下文字与背景的对比度、生成一组视觉等距的 UI 色阶、或适配 P3 广色域屏幕时，它能让 L 和 C 真正按你预期的方式工作——前提是每个 %、每个小数点、每处 @supports 位置都踩在线上。漏掉任何一个，它就安静地消失，而不是报错提醒你。
