OKLCH渐变“平滑”源于其坐标系更贴合人眼响应，但linear-gradient()仍强制sRGB插值；真正OKLCH插值需color-mix(in oklch)，且全链路单位与格式必须零容错。
linear-gradient() 里写 oklch() 并不等于 OKLCH 插值，浏览器仍强制用 sRGB 空间混合 —— 所以“更平滑”不是因为浏览器做了什么，而是你**手动控制插值路径时，OKLCH 的坐标系更贴合人眼响应**。
OKLCH 渐变“平滑”的真实前提是你没被 sRGB 拉垮
浏览器对所有 linear-gradient() 都走 sRGB 插值，哪怕两端是 oklch(0.6 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 插值的唯一 CSS 原语是 color-mix()
color-mix() 绕开了 linear-gradient() 的 sRGB 强制约束，直接在 OKLCH 空间做加权混合：
- 必须两端都是
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 尚未实现
- 要模拟多段渐变，只能手动嵌套多次
color-mix()，无法自动展开
用 linear-gradient() 模拟 OKLCH 平滑感的实操底线
当 color-mix() 不可用或需兼容旧环境时，靠停靠点逼近是最可行方案：
- 避免直写两段：不要
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)) - 叠加极低透明度噪点（
background-image: url("data:image/svg+xml,...")）可掩盖残余带状
最容易被忽略的硬门槛：全链路统一 + 单位零容错
OKLCH 渐变优势归零往往不是因为不会写，而是某处悄悄破防：
-
L缺单位（如oklch(60 0.28 258.5)）→ 整行静默失效，不是报错 - 混入一个
hsl()或rgb()→ 整条渐变 fallback 到 sRGB 插值 -
@supports写错检测值（如oklch(0 0 0)缺 %）→ 检测失败，OKLCH 永远不加载 - 深色模式切换时用了不同色彩空间 → 过渡帧发灰、偏色、对比度断崖下跌
