OKLCH写入linear-gradient()不启用OKLCH插值，浏览器始终强制sRGB插值；真正实现OKLCH插值需color-mix(in oklch)，且两端必须同为oklch()格式、单位合规，Chrome112+/Safari17.5+支持，Firefox尚未实现。
oklch() 写进 linear-gradient() 并不启用 OKLCH 插值
浏览器对 linear-gradient() 的插值始终强制在 sRGB 空间进行，哪怕你两端都写 oklch(0.5 0.25 240) 和 oklch(0.8 0.25 240)，中间色也是先转成 sRGB、再线性混合。这会导致：
- L 数值均匀上升，但视觉上发灰（尤其青蓝区 H≈210–270）
- 色相差 >180° 时（如 350°→10°），sRGB 插值被迫绕圈，C 被压缩，出现脏紫色带
- 同一 L+C 下只调 H，OKLCH 的感知一致性确实比 HSL 强，但前提是 C 不超限、H 不跨大弧、L 单位写对
真正启用 OKLCH 插值只能靠 color-mix(in oklch)
color-mix() 是当前唯一能绕过 linear-gradient() 的 sRGB 强制约束、在 OKLCH 空间做加权混合的 CSS 原语：
- 必须两端都是 oklch() 格式：color-mix(in oklch, oklch(0.5 0.2 240) 70%, oklch(0.8 0.15 250) 30%)
- 混用格式（比如一边是 #4a6fa5）整条失效，无降级、无提示
- Chrome 112+ / Safari 17.5+ 支持，Firefox 尚未实现
- 它只产出单点色值，无法直接替代渐变；要模拟多段，只能手动嵌套多次或借助构建时工具生成 ≥16 段停靠点
兼容旧环境时，停靠点 + 噪点才是实操底线
当 color-mix() 不可用或需覆盖 Safari 16.x、旧安卓 WebView 时，最可行的是控制插值路径本身：
- 避免直写两段：linear-gradient(oklch(0.3 0.25 240), oklch(0.7 0.25 240)) → 必然出灰带
- 改用三段停靠点：linear-gradient(oklch(0.3 0.25 240) 0%, oklch(0.5 0.24 242) 48%, oklch(0.7 0.25 240) 100%)，中间色选感知中位而非数值中位
- 色相差超 180° 必须拆段：linear-gradient(oklch(0.7 0.25 350), oklch(0.7 0.25 0), oklch(0.7 0.25 10))
- 叠加极低透明度 SVG 噪点：background-image: url("data:image/svg+xml,%3Csvg...")，可掩盖残余带状
全链路单位零容错是最容易被忽略的硬门槛
OKLCH 渐变优势归零往往不是因为不会写，而是某处悄悄破防：
- L 缺单位（如 oklch(60 0.28 258.5)）→ 整行静默失效，不是报错
- 混入一个 hsl() 或 rgb() → 整条渐变 fallback 到 sRGB 插值
- @supports 写错检测值（如 oklch(0 0 0) 缺 %）→ 检测失败，OKLCH 永远不加载
- 深色模式切换时用了不同色彩空间 → 过渡帧发灰、偏色、对比度崩塌
- 所有节点必须统一用 oklch()，包括自定义属性、transition、@media 块内声明
