oklch深色模式适配必须只降l、固定c和h，以保持色相稳定与对比度可控；l是经cie 2002校正的感知亮度标度，非rgb算术平均，实测同l值下各色相视觉明暗一致。
因为 OKLCH 的 L 通道直接对应人眼感知亮度，调 L 时色相（H）和色度（C）完全解耦——深色模式下只降 L、固定 C 和 H，就能让文字/图标在深底上既保持原色倾向，又维持可读性所需的对比度落差。
OKLCH 的 L 值不是“RGB 亮度百分比”，而是感知标度
HSL 的 L 是 RGB 三通道极值的算术平均，数学干净但视觉失真：同为 hsl(0, 100%, 50%)（纯红）和 hsl(120, 100%, 50%)（纯绿），实测 CIE Y 亮度分别是 ~0.21 和 ~0.72，差三倍。而 OKLCH 的 L 来自 OKLab 空间，经 CIE 2002 色貌模型校正，oklch(62% 0.28 258.5) 和 oklch(38% 0.28 258.5) 在人眼看来就是“同一蓝调，只是明暗不同”，对比度变化平滑可控。
深色模式必须只动 L，不动 C 或 H
一旦混着调参，视觉一致性就崩了：
- 如果同时降
L和C（比如oklch(38% 0.12 258.5)），蓝会发灰、发紫，尤其在 OLED 屏上出现 banding - 如果只降
C不动L（禁用态逻辑误用于深色模式），浅底变深底后文字瞬间“沉进背景”，对比度断崖下跌 - 如果微调
H（比如加 2° 补偿“看起来偏暖”），会导致全链路色相漂移，按钮组、图标、边框不再统一
@supports 检测写错，整条声明静默失效
OKLCH 不支持时浏览器不会报错，而是跳过整行 CSS —— 如果 fallback 没放对位置，UI 就直接黑/透明/错色：
- 降级色必须写在
@supports块**外部且上方**：background-color: #2563eb;→ 再写@supports (color: oklch(0% 0 0)) { ... } - 检测值必须带单位：
@supports (color: oklch(0% 0 0))✅，@supports (color: oklch(0 0 0))❌（Safari 17.4+ 也返回 false） - 绝不能用
@supports not—— 安卓 WebView 解析失败，整块规则被丢弃
渐变和 transition 中必须全链路统一色彩空间
哪怕你定义了 --primary: oklch(62% 0.28 258.5)，只要 hover 状态用了 hsl() 或 rgb()，浏览器就会 fallback 到 sRGB 插值，出现“先灰一下再显色”的过渡断裂。正确做法是：
- 深色模式下的
:hover、:active、:disabled全部用oklch()变体，例如oklch(35% 0.28 258.5) - 渐变跨色相 >180°（如 350°→10°）时，必须手动拆段：
linear-gradient(oklch(0.7 0.25 350), oklch(0.7 0.25 0), oklch(0.7 0.25 10))，否则中间段因数值线性插值产生灰紫色带 - DevTools 的 computed 样式里永远只显示降级后的十六进制值，真值只能靠肉眼比对 + 控制
C ≤ 0.28规避色域溢出
最常被忽略的一点：OKLCH 的可靠性不来自“它多先进”，而来自你是否严格约束参数语义——L 必须带 %，C 必须是无单位小数，H 后不加 deg，所有状态变体必须用同一色彩空间书写。漏掉任一细节，感知一致性就归零。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
