OKLCH文字色必须带单位，否则整条规则静默失效；L须用%或0–1、C为无单位小数、H不带deg、alpha用/分隔，@supports检测需写在降级色之后且值带单位，渐变跨色相需手动拆段，WCAG对比度须公式验算。
OKLCH文字色必须带单位，否则整条规则静默失效
浏览器对oklch()参数单位极其敏感：L必须用%或0–1小数，C必须是无单位小数（如0.28），H不能带deg，alpha必须用/分隔。写错任一单位，Chrome 112+、Safari 17.4+、Firefox 121+都会直接跳过该CSS声明——不报错、不警告、也不fallback到下一行。
常见错误写法：
-
oklch(60 0.2 240)❌ —— L缺% -
oklch(60% 20% 240)❌ —— C写成百分比 -
oklch(60% 0.2 240deg)❌ —— H后加deg在Safari 16.x和部分安卓WebView中解析失败 -
oklch(60% 0.2 240, 0.8)❌ —— alpha用逗号分隔，应为/
安全写法只有两种：oklch(60% 0.28 258.5)（兼容性最高），或oklch(0.6 0.28 258.5)（仅新浏览器支持，且H建议保留≤1位小数）。
@supports检测必须写在降级色之后，且值带单位
只靠两行颜色声明（先fallback，再oklch()）在部分安卓WebView中会彻底失效——它可能跳过所有后续规则。正确结构必须把降级色写在@supports块外部且上方，并确保检测值带单位。
立即学习“前端免费学习笔记（深入）”；
正确写法：
button { background-color: #2563eb; }
@supports (color: oklch(0% 0 0)) {
button { background-color: oklch(60% 0.28 258.5); }
}
错误写法：
-
@supports (color: oklch(0 0 0))❌ —— 缺单位，安卓WebView不识别 -
@supports not (color: oklch(0% 0 0))❌ ——not在安卓WebView中有解析bug -
oklch()声明写在@supports块外或顺序颠倒 ❌ —— 失效风险高
跨色相边界做渐变时，OKLCH不自动走短弧
CSS对oklch()渐变不做色相插值优化。比如oklch(0.7 0.25 350) → oklch(0.7 0.25 10)，浏览器会从350°经360°→0°→10°插值，中间段彩度塌陷、出现灰阶断层，而不是走350°→10°的10°短弧。
解决方法：
- 手动拆段：用多个
linear-gradient拼接，每段色相跨度控制在≤180° - 避免跨0°/360°：将目标色相映射到同一象限，例如把
10°改写为370°，与350°形成连续递增 - 优先用
L和C调节层次，少依赖大跨度H变化
WCAG对比度必须用公式验算，不能凭经验选OKLCH值
OKLCH感知均匀 ≠ 自动满足WCAG。浅色背景上用oklch(25% 0.01 240)看似够深，但实际对比度可能不足4.5:1。例如#ffffff配#333333是4.48:1（不达标），而#212529是4.67:1（刚好达标）。
实操要点：
- 始终用
(L1 + 0.05) / (L2 + 0.05)公式验算，L1为亮色、L2为暗色的相对亮度 - 开发阶段用Chrome DevTools无障碍面板或
contrast-ratio.com实时验证 - CI/CD中集成
contrast-rationpm包，在构建时扫描CSS变量自动报错 - 深色模式切换后必须重置文字色，不能复用浅色模式的
oklch()值——黑底oklch(25% 0.01 240)可能只剩2.1:1
OKLCH真正难的不是写法，而是你得同时盯住三件事：单位合法性、@supports结构完整性、以及WCAG数值真实性。漏掉任何一环，上线后颜色就“消失”或“发灰”，还查不出原因。
