oklch虽能解耦l/c/h，但其l值非线性、c值受l限制、h影响视觉明度，需实测对比度并严格按wcag感知要求调参；降级必须用@supports+外部fallback，渐变须拆段防断层，深色/高对比模式需独立适配。
OKLCH 是目前唯一能真正解耦亮度（L）、色度（C）、色相（H）的 CSS 原生颜色函数，但直接套用设计稿数值或 HSL 经验值，大概率导致文字可读性不达标、禁用态发灰、深色模式偏青紫——问题不在 OKLCH 本身，而在参数映射和降级逻辑没对齐 WCAG 的感知要求。
为什么 oklch() 的 L 值不能直接按 WCAG 对比度公式调？
WCAG 要求文本与背景对比度 ≥ 4.5:1，但这个比值基于 CIE Y（明度）计算，而 oklch() 的 L 是 OKLab 空间中经 CIE 2002 校正后的感知亮度坐标。它和 sRGB 的 gamma 曲线、人眼视锥响应都强关联，不是线性缩放关系。
-
oklch(30% 0.02 55)在浅底上可能只有 3.2:1，远低于标准；必须实测 —— 推荐用 Chrome DevTools 的「Contrast」面板或 axe DevTools 插件验证 - 同一
L值下，不同H（尤其蓝/紫系）在低C时视觉明度会塌缩：比如oklch(40% 0.08 270)看起来比oklch(40% 0.08 120)更暗 - 不要用
calc()直接加减L：从oklch(60% 0.28 258.5)减 20% 得到oklch(40% 0.28 258.5)，实际对比度可能断崖式下跌，因为低L区域的感知非线性更强
@supports + fallback 结构必须严格满足三要素
旧浏览器或安卓 WebView 不是“不支持 OKLCH”，而是静默跳过整条声明 —— 如果结构错，UI 就直接变黑、透明或错色，无障碍测试直接失败。
- 降级色必须写在
@supports块外部且上方：color: #1e293b;→ 然后才是@supports (color: oklch(0% 0 0)) { color: oklch(22% 0.02 55); } - 检测值必须带单位：
@supports (color: oklch(0% 0 0))✅；@supports (color: oklch(0 0 0))❌（Chrome/Safari 拒斥） - 绝对禁用
@supports not：安卓 WebView 解析该语法会崩溃整块 CSS 规则
禁用态、深色模式、高对比度模式要分策略调参
OKLCH 的优势是分工明确，但「一致」不等于「统一调参」。WCAG 2.2 新增的「强制颜色模式」（Windows 高对比主题、macOS Increase Contrast）会覆盖所有 CSS 颜色，所以你的 OKLCH 主题必须预留 fallback 路径。
- 禁用态：固定
H和L，只降C—— 例如oklch(22% 0.02 55)→oklch(22% 0.005 55)；若同时降L，浅背景上文字会糊成一片 - 深色模式：固定
H和C，只调L——oklch(96.8% 0.018 80)（奶油白）→oklch(14% 0.018 80)（暖灰黑），避免L降到 5% 以下导致 OLED 屏幕像素关断、文字边缘发虚 - 高对比度模式适配：用
@media (forced-colors: active)单独重写关键颜色，例如color: CanvasText;，此时 OKLCH 声明会被系统强制忽略
渐变和按钮悬停必须手动拆段，否则中间色断层
CSS 对 oklch() 渐变不做色相短弧插值。跨 0°/360° 时，浏览器按数值线性过渡，导致中间段 C 被压缩、出现难看的灰紫色带 —— 这在按钮悬停动效里尤为致命，直接影响可访问性焦点状态识别。
- 错误写法：
background: linear-gradient(oklch(0.7 0.25 350), oklch(0.7 0.25 10)); - 正确写法：色相差 >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 空间，失去感知均匀性，对比度骤降
最常被忽略的一点：OKLCH 的 C（色度）在低 L 下有硬性上限。例如 L:20% 时 C > 0.2 就可能溢出可见色域，渲染为不可预测的灰斑 —— 这类问题在深色模式下肉眼难辨，但自动对比度检测工具会报 fail。务必用真实设备+夜间模式+高对比设置交叉验证。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
