现代CSS推荐用oklch()替代hsl()，因其L值是CIE 2002校正的感知亮度坐标，同L值下红绿蓝视觉亮度一致；而hsl()的L仅为RGB极值算术平均，同L=50%时红绿亮度实测差三倍。
现代CSS推荐用 oklch() 替代 hsl()，不是因为它“更酷”或“更新”，而是因为 oklch() 的 L 真的代表人眼感知亮度——同一 L 值下，红、绿、蓝在视觉上真的差不多亮；而 hsl() 的 L 是 RGB 极值的数学平均，实测同为 L: 50%，纯红 CIE Y 亮度约 0.21，纯绿却达 0.72，差三倍。
oklch() 的 L 值为什么不能直接套用 hsl() 的数值
hsl() 的 L 是算术构造：取 max(R,G,B) 和 min(R,G,B) 的平均，和人眼无关；oklch() 的 L 是 OKLab 空间中经 CIE 2002 色貌模型校正的感知坐标。这意味着：
-
hsl(240, 100%, 50%)≈oklch(54% 0.32 240)，不是oklch(50% 0.32 240) - 深色模式切换时，把
oklch(62% 0.28 258.5)改成oklch(38% 0.28 258.5)，文字明暗变化平滑；若用hsl()，同样调L，蓝会发紫、黄会变灰 - 禁用态不要降
L，只降C：oklch(0.62 0.28 258.5)→oklch(0.62 0.12 258.5)，否则浅底文字对比度断崖下跌
@supports 检测和 fallback 写错就全黑
oklch() 不支持时浏览器不报错，而是整条声明静默跳过——UI 可能突然变透明、变黑或继承错误颜色。常见失效点：
- 降级色必须写在
@supports块**外部且上方**：background-color: #2563eb;，再跟@supports (color: oklch(0% 0 0)) { ... } - 检测值必须带单位：
@supports (color: oklch(0% 0 0))✅，@supports (color: oklch(0 0 0))❌（所有浏览器返回false） - 绝对别用
@supports not—— 安卓 WebView 解析异常，整块规则可能被忽略 - 别用
oklab()检测 —— 当前所有主流浏览器都返回false
OKLCH 渐变不是写对函数就生效
在 linear-gradient() 中写 oklch() 起止色，并不启用 OKLCH 插值。浏览器（Chrome 112+/Safari 17.5+/Firefox 120+）仍强制使用 sRGB 空间插值，中间色可能发灰、发紫。
立即学习“前端免费学习笔记（深入）”；
- 真正启用感知插值的唯一方式是
color-mix(in oklch, ...)，且两端必须都是oklch()格式 - 色相差超 180°（如 350° → 10°）时，CSS 不走短弧，必须手动拆段：
linear-gradient(oklch(0.7 0.25 350), oklch(0.7 0.25 0), oklch(0.7 0.25 10)) - 混用色彩空间（比如一段写
hsl()）会让整条渐变 fallback 到 sRGB，前功尽弃 -
L必须带单位：oklch(60% 0.28 258.5)✅，oklch(60 0.28 258.5)❌（静默失效）
OKLCH 的真正门槛不在“会不会写”，而在“能不能守住全链路统一”：自定义属性、transition、@supports 结构、渐变停靠点、甚至设计师给的原始色值白点（D65 还是 D50），只要一处松动，感知优势就彻底归零——而且这种失效是静默的，DevTools 里永远只显示降级后的 sRGB 十六进制值，你看不到真实行为。
