oklch是目前唯一实现l、c、h三者解耦的颜色函数：调l不偏色、调c不变亮、调h不失饱和，wcag对比度才可预测；其l值必须带%单位（如oklch(60% 0.28 258.5)）才能被浏览器正确解析并转为srgb计算相对亮度，否则将静默失效或降级为fallback色，导致wcag检测失真。
OKLCH不是“更适合”，它是目前唯一能让亮度（L）、色度（C）、色相（H）三者真正解耦、各自独立影响可访问性指标的颜色函数——调L不偏色、调C不变亮、调H不失饱和，WCAG对比度才可预测。
oklch() 的 L 值为什么必须带 % 单位才能参与 WCAG 计算
浏览器只有识别到 oklch(60% 0.28 258.5) 这类带单位的合法声明，才会在渲染时将其转为像素级相对亮度值，并套用 WCAG 公式；写成 oklch(60 0.28 258.5) 或 oklch(0.6 0.28 258.5)（无单位小数）在 Safari 17.4 以下、旧版安卓 WebView 中会被静默忽略，DevTools 显示 fallback 色，但 WCAG 面板仍按该 fallback 色计算——你以为在测 OKLCH，实际测的是 #2563eb。
-
oklch(60% 0.28 258.5)✅ 所有支持 OKLCH 的浏览器均能正确映射感知亮度，Chrome DevTools「Accessibility」面板显示的对比度数值才可信 -
oklch(60 0.28 258.5)❌ 所有浏览器跳过整条声明，UI 降级为上一条颜色（常是透明或黑色） -
oklch(0.6 0.28 258.5)⚠️ Chrome 112+/Firefox 121+/Safari 17.4+ 支持，但 H 小数位超过 1 位（如258.53）可能触发解析失败
@supports 检测写错就导致无障碍失效
OKLCH 不支持时不会报错，而是整条 color 或 background-color 声明被跳过——如果降级色没写对位置，文字可能直接变成透明或黑底白字，对比度归零。WCAG 检查工具扫出来的“通过”，其实是 fallback 色的假阳性。
- 降级色必须写在
@supports块外部且上方：background-color: #2563eb;，再跟@supports (color: oklch(0% 0 0)) { ... } - 检测值必须带单位：
@supports (color: oklch(0% 0 0))✅，@supports (color: oklch(0 0 0))❌（Safari 17.4+ 也返回 false） - 禁用
@supports not：安卓 WebView 存在解析 bug，会导致整个媒体查询块失效 - 别用
oklab()检测：所有主流浏览器目前都返回 false，毫无意义
色相跨 0° 边界时 OKLCH 渐变会破坏对比度连续性
CSS 对 oklch() 渐变不做色相短弧优化，oklch(0.7 0.25 350) → oklch(0.7 0.25 10) 会按数值线性插值：350 → 360 → 10，中间段 H=0° 附近 C 被强制压缩，出现灰紫色带——同一 L 下视觉亮度骤降，局部对比度跌破 WCAG 4.5:1。
- 色相差 >180° 时必须手动拆段：
linear-gradient(oklch(0.7 0.25 350), oklch(0.7 0.25 0), oklch(0.7 0.25 10)) - 每一段色相差 ≤180°，插值路径才不穿过低感知亮度区
- 混用色彩空间（比如其中一段写
hsl()）会让整条渐变 fallback 到 sRGB 插值，OKLCH 的感知均匀性彻底失效 - 禁用态不要动 L，只降 C：
oklch(0.62 0.28 258.5) → oklch(0.62 0.12 258.5)，否则浅底文字对比度断崖下跌
最常被忽略的是：Chrome DevTools「Accessibility」面板显示的对比度数值，永远基于真实渲染后的像素——它会把 oklch(32% 0.03 210) 先转成 sRGB 再套 WCAG 公式。你调的 L 值是否真等于感知亮度，只能靠肉眼比对 + 控制 C ≤ 0.28 来规避色域漂移风险。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
