必须实测对比度、分场景调参、严格fallback，否则深色/高对比模式下文字不可读；chrome devtools「accessibility」面板可实时验证，ci/cd可用contrast-ratio扫描，小字号文本需≥4.5:1，oklch的l值非线性，不可简单加减。
直接用 oklch() 写颜色不等于满足 WCAG；必须实测对比度、分场景调参、严格 fallback，否则在深色模式或高对比系统下文字会直接不可读。
怎么验证一对颜色是否真达标
别信“看着够亮”——#333 和 #f8f8f8 看似分明，实测只有 3.7:1，不满足普通文本 AA 级（≥4.5:1）要求。Chrome DevTools 的「Accessibility」面板能实时显示当前元素的对比度数值和是否通过；CI/CD 中可用 contrast-ratio npm 包扫描 CSS 变量，在构建时报出所有不合规组合。
- 小字号常规文本：必须 ≥ 4.5:1
- 大号文本（≥18pt 或 ≥14pt 加粗）：可放宽至 ≥ 3:1
- 禁用态、悬停态、焦点态都要单独验证，不能只测默认态
为什么 oklch() 的 L 值不能线性调整
oklch(60% 0.28 258.5) 减去 20% 得到 oklch(40% 0.28 258.5)，实际对比度可能从 7.2:1 断崖跌到 3.1:1。因为 OKLCH 的 L 是感知亮度坐标，低 L 区域非线性极强，尤其在 OLED 屏上，L
- 同一 L 下，蓝/紫系（H ≈ 270）视觉明度明显低于黄绿系（H ≈ 120）
- 禁用态建议固定 L 和 H，只降 C：
oklch(22% 0.02 55)→oklch(22% 0.005 55) - 深色模式建议固定 H 和 C，只调 L：
oklch(96.8% 0.018 80)→oklch(14% 0.018 80)，避免低于 10%
@supports 降级结构怎么写才不崩溃
安卓 WebView 遇到 @supports not 会静默丢弃整条规则，UI 直接变黑或透明；Chrome/Safari 拒斥无单位的检测值。正确结构必须三要素齐全：
- fallback 色写在
@supports块外部且上方：color: #1e293b; - 检测语句带单位：
@supports (color: oklch(0% 0 0)) { color: oklch(22% 0.02 55); } - 绝对禁用
@supports not，改用正向检测 + 外部 fallback
动态背景上怎么让文字自动可读
目前没有浏览器原生支持 color-contrast()（草案阶段），但 Chrome 111+/Safari 16.4+ 可用 color-mix() + relative-color() 组合实现轻量级适配：
- 必须配合
@property声明变量为color类型，否则relative-color()解析失败 -
color-mix()只能混合两个已知色，不能凭空生成新色；适合“背景越暗，文字越白”这类阈值切换 - 真正动态场景（如 Canvas 渲染背景、渐变叠加）仍需 JS 获取真实渲染色再计算 luminance
最易被忽略的是：高对比度系统（Windows 强制颜色主题、macOS Increase Contrast）会覆盖所有 CSS 颜色，OKLCH 主题必须预留 prefers-contrast: high 独立规则路径，不能只靠 fallback。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
