旧浏览器对display-p3或oklch会静默跳过整条color声明，导致“失色”；必须前置合法fallback（如#2563eb）、后置@supports检测，且<meta>与color-gamut声明缺一不可。
旧浏览器遇到 display-p3 或 oklch 会直接“失色”
不是变灰，不是降级，是整条 color 或 background-color 声明被静默跳过。IE11、Android 4.4 WebView、Chrome 110 及更早版本里，color: color(display-p3 0.98 0.35 0.35) 和 color: oklch(60% 0.28 258.5) 都等于没写——文字可能继承黑色或透明，按钮背景变成默认白底，排版瞬间崩坏。
根本原因不是浏览器“不支持函数”，而是它根本不认识这些值作为 color 属性的合法取值。规范要求：无法识别的值 → 跳过该声明 → 继续解析下一条。所以 fallback 能否生效，只取决于它是否独立、前置、且语法合法。
fallback 必须写在 @supports 外部且顺序固定
很多人把 @supports 块写在前面，fallback 放后面，结果在 Chrome 110 和部分 WebView 中整条颜色声明都失效。这是因为某些早期 Chromium 实现会把同名属性（比如连续两个 color:）当成一个逻辑块处理，一旦开头被忽略，后续也一并丢弃。
- ✅ 正确顺序：
color: #2563eb;→ 紧接着写@supports (color: oklch(0% 0 0)) { color: oklch(60% 0.28 258.5); } - ❌ 错误顺序：
@supports (color: oklch(0% 0 0)) { color: oklch(60% 0.28 258.5); }→ 后面再写color: #2563eb; - ⚠️ IE11 完全不解析
@supports，但它能读取并应用外部那行#2563eb—— 前提是这行没被包裹、没混用新语法（如inset或gap）
display-p3 的 fallback 不只是换颜色，还要配 meta 和 color-gamut
color(display-p3) 不是普通颜色函数，它依赖整个渲染链路开启 P3 色彩空间。只写 fallback 颜色远远不够：
立即学习“前端免费学习笔记（深入）”；
-
<meta name="color-scheme" content="light dark">必须放在<head>最顶部，早于所有 CSS 引入 - CSS 中必须先声明
html { color-gamut: p3; }（哪怕只是占位），否则 Safari 旧版本拒绝启用 P3 渲染 -
color(display-p3)的参数是线性 P3 坐标（0–1），不能从 sRGB 十六进制硬拆。比如#FF6B6B直接转成1, 0.42, 0.42是错的，会严重发灰；必须用专业工具做色域映射 - fallback 必须前置：
color: #FF6B6B;→ 再写color: color(display-p3 0.98 0.35 0.35);
oklch / lch 的单位和检测写法极易出错
oklch 和 lch 看似相似，但参数规则完全不同，错一个单位整条声明就静默失效：
-
oklch()：L 和 C 后必须跟%，H 无单位（258.5✅，258.5deg❌） -
lch()：L 和 C 后必须跟%，H 后必须跟deg（240deg✅，240❌） - @supports 检测必须用
(color: oklch(0% 0 0))，不是(color: oklab(0 0 0))（主流浏览器仍返回 false） - 别用
var(--c, #000)救oklch：变量本身会被跳过，var()第二参数只在变量未定义或语法非法时触发，而oklch(...)是合法语法
真正难的不是写对语法，而是设计稿、Figma 输出、开发环境显示器、用户设备全部跑在 sRGB 上，却指望 LCH 值跨链路保真——它只优化计算过程，不解决底层色彩管理断层。
