OKLCH渐变不自动防暗，需手动解耦L/C/H控制；浏览器仍强制linear-gradient在sRGB插值，真正防暗须用color-mix(in oklch)；色相差超180°须拆段，混用色彩空间将静默失效。
OKLCH渐变本身并不会“不发暗”——它只是把“发暗”这个现象从固有缺陷，变成了可预测、可控制的参数行为。真正起作用的不是OKLCH自动防暗，而是你用对了L/C/H的解耦逻辑。
linear-gradient()里写oklch() ≠ OKLCH空间插值
浏览器目前（Chrome 112+/Safari 17.5+/Firefox 120+）仍强制所有linear-gradient()在sRGB空间做线性混合。哪怕你写了oklch(0.7 0.25 240)到oklch(0.9 0.25 240)，中间帧仍是先转sRGB再插值，亮度曲线还是非感知均匀的——所以依然会发灰、发暗。
- 想获得真正不发暗的过渡，必须绕过
linear-gradient()，改用color-mix(in oklch, ...) -
color-mix()两端颜色必须都是oklch()格式，且单位一致（如都用60%） -
in oklch语法在linear-gradient()中无效，写了会被忽略或解析失败
OKLCH渐变“不发暗”的前提是L和C被独立控制
OKLCH的L是感知亮度坐标，C是归一化色度，二者解耦。当只调L（比如oklch(60% 0.28 258.5) → oklch(38% 0.28 258.5)），蓝调稳定、不漂移、不突兀变紫；而HSL里同L值红绿亮度差三倍，调L必然伴随色相/饱和度失真，视觉上就表现为“暗得不自然”。
- 深色模式适配：固定C和H，只降L —— 明暗变化均匀，不会突然压暗文字导致对比度断崖下跌
- 禁用态处理：固定L和H，只降C（如
0.28→0.12）—— 颜色变灰但不发黑，浅底文字仍保可读性 - 切忌同时大幅调L和C：插值路径可能穿过低感知亮度区，反而更暗
色相差超180°时，不拆段就会强制穿暗区
OKLCH不自动做色相短弧优化。从oklch(0.7 0.25 350)到oklch(0.7 0.25 10)，浏览器按数值走350→360→10，中间段C被压缩，出现灰紫色带——这不是“发暗”，而是色度塌陷导致的视觉沉闷感。
立即学习“前端免费学习笔记（深入）”；
- 必须手动拆段：
linear-gradient(oklch(0.7 0.25 350), oklch(0.7 0.25 0), oklch(0.7 0.25 10)) - 每段色相差 ≤180°，才能避免插值路径穿过低亮度高色度交叠区
- 混入任意一个
hsl()或rgb()停靠点，整条渐变立刻fallback到sRGB插值，前功尽弃
最常被忽略的点：L缺%、C写成百分比、H加deg、混用色彩空间——这些都不会报错，而是整条声明静默失效。你以为渐变“没发暗”，可能只是根本没生效。
