color-mix()和oklch()需按真实UA统计验证支持性，必须用@supports(color: color-mix(in srgb, red, blue))检测并配静态fallback，否则整条声明静默失效。
别急着用 color-mix() 或 oklch()，先看它在目标用户设备上是否真能生效——多数新函数目前只在特定浏览器版本中可用，且行为不一致，盲目上线容易导致颜色错乱或回退成透明/黑色。
查清目标环境的最小支持版本
不是“Chrome 支持”，而是“Chrome 117+ 且启用了 #enable-color-gamut-p3 实验性 flag 才支持 color(display-p3)”；color-mix() 虽在 Chrome 115+、Safari 16.4+、Firefox 119+ 原生支持，但 Safari 对 in lch 仍不识别；oklch() 在 Firefox 中需 -moz-oklch() 前缀，且插值逻辑与 Chrome 不同。必须按实际用户 UA 统计（比如你后台数据显示 82% 用户用 Chrome 120+，那 color-mix(in srgb, ...) 就可放心用）。
- 用
@supports (color: color-mix(in srgb, red, blue))检测，而不是靠@media (color-gamut: p3) - 真机测试不可省：Safari 开发者工具里
color(display-p3)显示为灰色无效值，但 iPhone 14 Pro 上可能正常渲染 - CI 流程中加入 caniuse-lite 检查，避免 PR 合并后才发现
lab(50% 40 60)在旧 Edge 中被整条规则丢弃
确认 fallback 是否真正可控
新函数的 fallback 不是“自动降级”，而是“整条声明失效”。比如写 color: oklch(60% 0.2 270); color: #3b82f6;，旧浏览器会忽略第一行，用第二行；但若写成 background: linear-gradient(oklch(60% 0.2 270), oklch(30% 0.2 270));，整个渐变会退化为 transparent，而非 fallback 到 linear-gradient(#3b82f6, #1e40af)。
- 所有新函数都必须配显式 fallback，且 fallback 值不能依赖变量（
var(--primary)在不支持函数的 UA 中不会计算） -
color-mix()无法 fallback 到变量或currentColor，只能写死两个具体颜色值 - 用 PostCSS 插件（如
postcss-color-mix）做构建时降级，比运行时 JS 补丁更可靠
警惕“看起来一样”的陷阱
同一段 hsl(200 100% 50%) 在 Chrome 和 Firefox 中渲染差异不大，但 lch(50% 70 25) 在不同引擎下亮度感知偏差可达 ±12%，尤其在深色背景下文字可读性可能不达标；color-mix(in srgb, #2563eb, #1e40af) 和 color-mix(in lch, #2563eb, #1e40af) 输出色值完全不同，后者更均匀，但 Safari 不支持，强行用会白屏。
立即学习“前端免费学习笔记（深入）”；
- WCAG 对比度检测必须用真实渲染结果，不能只验 sRGB 值——
oklch()的l值接近人眼感知，但工具链（如 axe-core）尚未适配 - 设计稿给的是 sRGB 十六进制，直接转
oklch()会偏色，必须经 ICC 配置文件转换，否则 iPhone 上看起来发灰 - 动画中使用
hsl()插值，在 Firefox 中走 HSL 圆柱路径，Chrome 走 RGB 线性路径，过渡色可能完全不一致
最常被忽略的点：新颜色函数不是“增强”，而是“新增语义层”。一旦引入，就得为每种函数维护独立的测试用例、设计系统文档和 QA checklist——比如 color-mix() 必须验证权重归一化行为，oklch() 必须验证 c 值溢出时的裁剪策略。没配套就上线，等于把色彩控制权交给了浏览器实现细节。
