css color level 4是w3c候选推荐标准，非所谓“css4”，其color-contrast()、color-mix()、lch()/oklch()等新能力聚焦感知均匀亮度控制，以精准满足wcag aa级（≥4.5:1）文本可读性要求。
CSS4 并不存在官方标准，“CSS4 颜色规范”是误称；真正落地的是 CSS Color Level 4（W3C 候选推荐标准），它新增的 color-mix()、color-contrast()、lch()、oklch() 等能力，核心目标不是“炫技”，而是让开发者能更可靠地控制人眼感知到的亮度与对比度——而这直接决定 WCAG AA 级文本可读性是否达标。
为什么 lch() 和 oklch() 比 rgb() / hsl() 更适合无障碍配色
rgb() 和 hsl() 的数值变化不线性对应人眼明暗感知：比如 hsl(0, 0%, 50%)（中灰）和 hsl(0, 0%, 51%)（略亮灰）在屏幕上几乎看不出差别，但 WCAG 对比度计算要求的是**相对亮度 L**，必须基于感知均匀色彩空间。
-
lch()和oklch()中的L通道直接代表感知亮度（0=纯黑，100=纯白），调高 5 个单位 ≈ 人眼可辨识的明暗变化，便于精准卡住 4.5:1 所需的最小亮度差 -
oklch()是lch()的改进版，解决了蓝紫色区域亮度塌陷问题，在 OLED 屏或深色背景下更稳定 - 浏览器 DevTools 已支持在颜色拾取器中输入
oklch(60% 0.2 270)并实时预览，但注意：Safari 17+、Chrome 119+、Firefox 120+ 才完整支持，旧版本会忽略整条声明
color-contrast() 函数的真实能力和边界
color-contrast() 不是“自动变色神器”，它只在明确背景色前提下，从一组候选色里挑出对比度最高的那个。它解决不了底层逻辑缺陷：
- 必须显式声明
background-color；若背景是background-image或渐变，函数返回transparent或直接失效 - 不处理半透明叠加：写
color: color-contrast(white vs black, #333, #666); background-color: rgba(0,0,0,0.8);，函数仍按纯 black 计算，而实际渲染背景是混合后的深灰，结果不可信 - 降级必须前置：
color: #333; color: color-contrast(white vs black, #333, #e0e0e0);，否则不支持的浏览器会丢弃整条规则 - 目前仅 Safari 16.4+ 和 Chrome Canary 稳定支持；Firefox 尚未实现
用 color-mix() “保对比度”为何常翻车
color-mix() 只做线性插值，不校验 WCAG 公式中的非线性亮度转换（(L1 + 0.05) / (L2 + 0.05)）。常见误用场景：
-
color: color-mix(in srgb, var(--text-primary) 80%, white 20%);—— 看似提亮，但若原始--text-primary是#666，混合后仍是低对比灰，工具一测可能只有 3.2:1 - 在深色模式下对同一变量做
color-mix(in srgb, var(--text-primary) 30%, black 70%)，反而把本已合规的浅灰压成不可读的暗灰 - 它无法感知父容器
opacity或 backdrop-filter 影响，这些都会改变最终渲染亮度，但函数无从知晓
真正可靠的路径仍是：用 oklch() 定义语义色板 → 在 @media (prefers-color-scheme: dark) 中切换整套 L 值 → 对按钮文字、placeholder、disabled 态等高风险元素单独验证渲染后色值。工具不会骗人，但人会绕过工具去“凭感觉写 color-mix”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
