oklch本身不保证wcag合规，但其l值是唯一对应人眼感知亮度的标尺，可精准支撑wcag对比度公式计算；hsl的lightness仅为srgb几何中点，同值不同色相的实际亮度差异可达三倍，无法可靠控对比度。
OKLCH 本身不保证 WCAG 合规，但它是唯一能让你“算得准”对比度的色彩空间——所有 WCAG 对比度计算都基于亮度（L）值，而 OKLCH 的 L 就是感知亮度，直接对应公式中的 (L_text + 0.05) / (L_bg + 0.05)。
为什么不能直接用 hsl() 调亮度来控对比度
HSL 的 lightness 是 sRGB 立方体几何中点，不是人眼感知亮度。比如 hsl(0, 100%, 50%)（纯红）实际相对亮度 ≈0.21，而 hsl(120, 100%, 50%)（纯绿）≈0.72 —— 数值一样，真实亮度差三倍。你调 hsl() 的 lightness，永远不知道最终对比度会崩到哪。OKLCH 的 L 是统一标尺：oklch(55% 0.2 240) 和 oklch(55% 0.2 0) 在视觉明度上完全一致，差值可直接用于 WCAG 计算。
@supports (color: oklch(0% 0 0)) 必须写对且 fallback 必须前置
错一个单位，整条 oklch() 静默失效，文字可能变透明或继承父级色 —— 这是线上对比度“突然不达标”的头号原因。
- 检测语法必须是
@supports (color: oklch(0% 0 0))：L带%、C是小数、H无单位，缺一不可 - 绝对禁用
@supports not (color: oklch(0% 0 0))：安卓 WebView 会解析崩溃整块 CSS - fallback 必须写在
@supports块外部且上方，例如：color: #e0e0e0;放第一行，@supports块放第二行；颠倒顺序会导致 Chromium 跳过 fallback
背景 L 值怎么查？文字最低 L 怎么算？
查背景 L 值：用 DevTools 取色 → 粘贴到 ColorMe 或浏览器原生 Color Picker，看输出的 L（如 #2d2d2d ≈ L:20）。
算文字最低 L：WCAG AA 要求 ≥4.5:1 → 公式为 (L_text + 0.05) / (L_bg + 0.05) ≥ 4.5 → 解得 L_text ≥ L_bg × 4.5 − 0.05 × 3.5，经验阈值可简化为 L_text ≥ L_bg + 55（仅适用于 L_bg 在 10–40 区间）。
- 背景
L=20，文字至少设oklch(75% 0.02 240)，不是hsl(240, 0%, 85%)（它L≈62，不够） - 选色时盯死
L，别被C（饱和度）和H（色相）干扰判断 - 小字号文本（≤14pt 加粗 / ≤18pt 常规）必须按 4.5:1 算；大文本可放宽至 3:1，但依然要实测
OKLCH 不是终点，实测才是唯一验证方式
Chrome DevTools「Accessibility」面板显示的对比度数值，永远基于真实渲染后的像素——它会把 oklch(32% 0.03 210) 先转成 sRGB，再套 WCAG 公式。CI/CD 中用 contrast-ratio 扫描 CSS 变量时，也必须走这一步转换。
最容易被忽略的是：@media (forced-colors: active)（高对比模式）下，系统会强制重映射颜色，此时 OKLCH 定义的原始 L 完全失效；禁用态、焦点态也可能被覆盖。必须用 CanvasText 这类系统关键词兜底，不能只依赖 OKLCH 声明。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
