oklch是唯一能保证感知亮度一致的颜色函数:调l不偏色、改c不塌亮、换h不失饱和;但需正确书写、降级和处理插值边界,否则比hex更易出错。

oklch() 不是“更炫的 HEX”,它是唯一能让颜色令牌在明暗模式、不同设备、不同色相间保持**感知亮度一致**的颜色函数——调 L 真的不偏色,改 C 真的不塌亮,换 H 真的不失饱和。但前提是写对、降级对、插值边界也处理对,否则比用 #2563eb 还容易翻车。
为什么OKLCH能解决HEX在设计系统里的根本缺陷
HEX 是 sRGB 设备空间的快照,没有语义:#2563eb 在浅底上可读,在深底上就糊成一片;想生成禁用态?只能靠经验减灰或加透明,结果文字在浅背景上对比度断崖下跌。而 oklch() 的 L 是 CIE 2002 校正后的感知亮度坐标,同一 L=62% 下,蓝(258.5°)、紫(300°)、绿(120°)在人眼看来明度基本一致。
这意味着:
• 深色模式只需改 L:从 oklch(62% 0.28 258.5) → oklch(38% 0.28 258.5),文字始终清晰
• 禁用态只降 C:从 0.28 → 0.12,避免 L 一动,浅底文字直接“消失”
• 悬停态微调 L 或 C 都不会意外发灰——HEX 或 HSL 里调个亮度,蓝变紫、绿变黄,是常态
@supports 降级结构错一个位置,整套令牌就失效
oklch() 不支持时不是报错,而是整条声明被浏览器静默跳过。如果降级色没写在正确位置,UI 可能全黑、全透明,或直接显示继承色。
必须遵守这个顺序:
• 先写 fallback:background-color: #2563eb;
• 再用 @supports 包裹现代色:@supports (color: oklch(0% 0 0)) { background-color: oklch(60% 0.28 258.5); }
• @supports 值必须带单位:oklch(0% 0 0) ✅,oklch(0 0 0) ❌(所有主流浏览器返回 false)
• 绝对不用 @supports not:安卓 WebView 有解析 bug,整块规则可能被忽略
渐变和动画中色相跨 0° 边界时,OKLCH 会自动走“长弧”
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():混入 hsl() 或 rgb(),整条渐变 fallback 到 sRGB 插值,前功尽弃
• H 后不能加 deg:Safari 16.x 和部分安卓 WebView 会解析失败
参数单位错一个,整行 CSS 就静默消失
这是最常踩却最难排查的坑:浏览器不报错、不警告、也不 fallback,就当那行不存在。L 必须带 %(如 60%)或小数(如 0.6),但后者仅 Chrome 112+/Firefox 121+/Safari 17.4+ 支持,稳妥起见统一用 60%C 必须是无单位小数(如 0.28),写成 28% 或 28 都会被忽略H 单位只能是纯数字(如 258.5),加 deg 在旧环境解析失败
alpha 必须用 / 分隔:oklch(60% 0.28 258.5 / 0.8) ✅,逗号写法 oklch(60%, 0.28, 258.5, 0.8) ❌
oklch() 值,computed 样式只显示降级后的十六进制;真值只能靠肉眼比对 + 限制 C ≤ 0.28 控制色域漂移风险。前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!











