OKLCH是唯一能保证感知亮度一致的颜色函数：调L不偏色、改C不塌亮、换H不失饱和；但需正确书写、降级和处理插值边界，否则比HEX更易出错。
oklch() 不是“更炫的 HEX”，它是唯一能让颜色令牌在明暗模式、不同设备、不同色相间保持**感知亮度一致**的颜色函数——调 L 真的不偏色，改 C 真的不塌亮，换 H 真的不失饱和。但前提是写对、降级对、插值边界也处理对，否则比用 #2563eb 还容易翻车。
为什么OKLCH能解决HEX在设计系统里的根本缺陷
HEX 是 sRGB 设备空间的快照，没有语义：#2563eb 在浅底上可读，在深底上就糊成一片；想生成禁用态？只能靠经验减灰或加透明，结果文字在浅背景上对比度断崖下跌。而 oklch() 的 L 是 CIE 2002 校正后的感知亮度坐标，同一 L=62% 下，蓝（258.5°）、紫（300°）、绿（120°）在人眼看来明度基本一致。
这意味着：
• 深色模式只需改 L：从 oklch(62% 0.28 258.5) → oklch(38% 0.28 258.5)，文字始终清晰
• 禁用态只降 C：从 0.28 → 0.12，避免 L 一动，浅底文字直接“消失”
• 悬停态微调 L 或 C 都不会意外发灰——HEX 或 HSL 里调个亮度，蓝变紫、绿变黄，是常态
@supports 降级结构错一个位置，整套令牌就失效
oklch() 不支持时不是报错，而是整条声明被浏览器静默跳过。如果降级色没写在正确位置，UI 可能全黑、全透明，或直接显示继承色。
必须遵守这个顺序：
• 先写 fallback：background-color: #2563eb;
• 再用 @supports 包裹现代色：@supports (color: oklch(0% 0 0)) { background-color: oklch(60% 0.28 258.5); }
• @supports 值必须带单位：oklch(0% 0 0) ✅，oklch(0 0 0) ❌（所有主流浏览器返回 false）
• 绝对不用 @supports not：安卓 WebView 有解析 bug，整块规则可能被忽略
渐变和动画中色相跨 0° 边界时，OKLCH 会自动走“长弧”
CSS 对 oklch() 渐变不做色相短弧优化。写 oklch(0.7 0.25 350) → oklch(0.7 0.25 10)，浏览器按数值线性插值：350 → 360 → 10，中间段 H=0° 附近 C 被强制压缩，出现难看的灰紫色带。
必须手动拆段：
• 色相差 >180° 时，补一个中间停靠点：linear-gradient(oklch(0.7 0.25 350), oklch(0.7 0.25 0), oklch(0.7 0.25 10))
• 所有节点必须统一用 oklch()：混入 hsl() 或 rgb()，整条渐变 fallback 到 sRGB 插值，前功尽弃
• H 后不能加 deg：Safari 16.x 和部分安卓 WebView 会解析失败
参数单位错一个，整行 CSS 就静默消失
这是最常踩却最难排查的坑：浏览器不报错、不警告、也不 fallback，就当那行不存在。L 必须带 %（如 60%）或小数（如 0.6），但后者仅 Chrome 112+/Firefox 121+/Safari 17.4+ 支持，稳妥起见统一用 60%C 必须是无单位小数（如 0.28），写成 28% 或 28 都会被忽略H 单位只能是纯数字（如 258.5），加 deg 在旧环境解析失败
alpha 必须用 / 分隔：oklch(60% 0.28 258.5 / 0.8) ✅，逗号写法 oklch(60%, 0.28, 258.5, 0.8) ❌
立即学习“前端免费学习笔记（深入）”；
DevTools 里永远看不到真实oklch() 值，computed 样式只显示降级后的十六进制；真值只能靠肉眼比对 + 限制 C ≤ 0.28 控制色域漂移风险。 
