OKLCH声明在旧浏览器中并非“变灰”，而是整条被忽略，最终回退到继承值或UA默认值（如color为黑色）；正确降级必须在同一属性内按层叠顺序前置RGB fallback，如background-color: #4a6fa5; background-color: oklch(60% 0.18 250);。
OKLCH 颜色在低版本浏览器里显示为灰色，根本不是“变灰”，而是整条 oklch() 声明被浏览器直接忽略，最终取父级继承值或 UA 默认值（比如 color 默认是黑色，background-color 默认是透明），在深色背景上文字就看不见了——你看到的“灰色”其实是 fallback 缺失导致的意外结果。
OKLCH 声明为什么在 Safari/Firefox/旧 Chrome 里“消失”
浏览器遇到不支持的 oklch() 函数时，不会报错，也不会尝试降级，而是按 CSS 语法规范直接丢弃整条声明。例如：
.text-primary { color: oklch(60% 0.25 240); }在 Safari 16.3 或 Firefox 120 中，这行完全不生效，元素会继承父级 color（常是 #000）或回退到用户代理默认值。
-
@supports (color: oklch(0% 0 0))在不支持的浏览器中也会被跳过——它本身依赖oklch()语法，解析器连函数名都认不出 -
CSS.supports('color', 'oklch(0% 0 0)')返回false，但你无法区分是函数不支持，还是参数格式错误 - 把
oklch()和rgb()拆成两个 class（如.text-rgb+.text-oklch）毫无意义：旧浏览器根本不会应用第二个 class
正确 fallback 必须用层叠顺序，不能靠 JS 或 @supports
唯一可靠的方式，是在同一选择器、同一属性下，按从上到下的顺序写多个声明，让浏览器自然取第一个有效值：
立即学习“前端免费学习笔记（深入）”；
.btn {<br> background-color: #4a6fa5;<br> background-color: oklch(60% 0.18 250);<br>}- RGB（或
rgba()）必须写在前面，oklch()写在后面——顺序反了就全失效 - 如果用了 alpha，fallback 必须是
rgba(74, 111, 165, 0.9)，不能用#4a6fa599（HEX8 不是所有旧浏览器都支持） - 绝对不要用
@supports把oklch()包起来再放 fallback 在里面：fallback 必须在@supports外部、同一选择器下 - PostCSS 插件（如
@csstools/postcss-oklab-function）能自动生成 fallback，但要设preserve: true，否则会删掉原始oklch()
十六进制 fallback 怎么选才不发灰、不失真
oklch() 的色度 c 在 sRGB 中没有直接映射，自动转换工具（如 postcss-oklab）会 clamp 超出色域的值，尤其蓝紫和高饱和绿区域容易视觉发灰：
- oklch(0.5 0.3 240) → 自动转成 rgb(102, 128, 255)，实际看起来比预期更灰
- oklch(0.9 0.4 120) → 转成 rgb(180, 255, 160)，饱和度下降约 15%
- 对品牌主色等关键颜色，建议人工校验：用 Björn’s OKLCH Picker 或 colorjs.io 导出 RGB，并在真机（尤其是 MacBook LCD 屏）上比对
- 若精度要求极高，可用
/* postcss-ignore */注释跳过该行，手写经过验证的rgb()或hsl()
真正容易被忽略的点是：开发者工具里看到的永远是 fallback 后的 sRGB 值，getComputedStyle(el).color 也只返回十六进制，想确认 OKLCH 是否生效，只能靠视觉比对 + 控制色度上限（日常建议 c ≤ 0.28）。
