OKLCH是唯一实现L、C、H三者真正解耦的颜色函数，调参需严格遵循单位规范（L用%，C用无单位小数，H不加deg），且必须配合正确@supports检测与降级策略才能保障跨浏览器一致性。
OKLCH 不是“更好用的 HSL”，它是唯一能让 L（亮度）、C（色度）、H（色相）三者真正解耦的颜色函数——调 L 不偏色、调 C 不变亮、调 H 不失饱和。只要参数写对、链路统一、降级合理，就能做出人眼感知一致的调色板。
oklch() 参数单位错一个，整条声明就静默失效
浏览器不会报错，也不会 fallback 到下一条；它直接跳过整行 CSS。这是所有问题的起点。
-
oklch(60 0.28 258.5)❌ —— L 缺%，Chrome 112+ 和 Safari 17.4+ 都拒斥 -
oklch(60% 28% 258.5)❌ —— C 必须是无单位小数（如0.28），不能写成百分比 -
oklch(60% 0.28 258.5deg)❌ —— H 后加deg在 Safari 16.x 和部分安卓 WebView 中解析失败 -
oklch(60% 0.28 258.5 / 0.8)✅ —— alpha 必须用/分隔，不能用逗号
安全写法只有两种：oklch(60% 0.28 258.5)（全版本兼容性最高），或 oklch(0.6 0.28 258.5)（仅 Chrome 112+/Firefox 121+/Safari 17.4+，且 H 小数位建议 ≤1）。
@supports 检测必须写在降级色之后，且值带单位
只靠两行颜色声明（先 fallback，再 oklch）在部分安卓 WebView 中会完全失效——它可能跳过所有后续规则，导致 OKLCH 彻底不加载。
立即学习“前端免费学习笔记（深入）”；
- 降级色必须写在
@supports块外部且上方，否则某些环境会忽略整个块 - 检测值必须带单位：
@supports (color: oklch(0% 0 0))✅，@supports (color: oklch(0 0 0))❌ - 绝对不要用
@supports not (color: oklch(0% 0 0))—— 安卓 WebView 存在解析 bug - 别用
oklab()替代检测 —— 所有主流浏览器目前都返回false
正确结构示例：
button { background-color: #2563eb; }
@supports (color: oklch(0% 0 0)) {
button { background-color: oklch(60% 0.28 258.5); }
}
跨色相渐变必须手动拆段，否则中间出灰带
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()会导致插值 fallback 到 sRGB 空间，失去感知均匀性 - 动画和 transition 同理：哪怕定义了
--primary: oklch(62% 0.28 258.5)，hover 状态用了hsl()，浏览器就会走 sRGB 插值，出现“先灰一下再显色”
深色模式和禁用态要用不同策略调参
OKLCH 的一致性来自参数分工明确，但调参逻辑不能一概而论。
- 禁用态：固定 H 和 L，只降 C —— 例如从
oklch(0.62 0.28 258.5)→oklch(0.62 0.12 258.5)，避免文字在浅底上可读性断崖下跌 - 深色模式：固定 H 和 C，只调 L —— 例如
oklch(0.62 0.28 258.5)→oklch(0.38 0.28 258.5)，视觉过渡平滑，不发青也不发紫 - 别把 L 当“百分比亮度”用：它是无量纲感知标度（0 = 黑，1 = 白）；
oklch(50% 0.2 240)和oklch(0.5 0.2 240)数值等价，但前者兼容性高得多
最常被忽略的是：OKLCH 的 L 值无法从设计稿里的 HSL 直接换算。比如品牌主色 hsl(240, 70%, 50%) 不能简单改成 oklch(50% 0.28 240)，结果蓝变灰紫——必须用在线转换器重采样，或通过构建时工具（如 postcss-oklab）统一处理。
