OKLCH的L恒定不等于UI明暗恒定，因需统一单位、隔离色相、分离禁用态与深色模式的L/C控制，并避免混用色彩空间导致sRGB降级。
OKLCH 的 L 值必须恒定才能实现感知亮度一致，但直接写死 L 并不等于 UI 真的“亮度稳定”——关键在于单位统一、色相隔离、禁用态与深色模式的 L/C 分离控制，以及避免混用色彩空间触发 sRGB 降级。
为什么 oklch() 的 L 恒定 ≠ UI 明暗恒定
OKLCH 的 L 是感知亮度坐标，同一 L 值（如 60%）在红、蓝、绿等不同色相下人眼感受基本一致；但若你在 CSS 中混用 oklch(60% 0.28 240) 和 hsl(240, 100%, 50%)，或在 transition 中交叉引用 --primary: oklch(...) 和 --hover: hsl(...)，浏览器会强制 fallback 到 sRGB 插值——结果是悬停时先发灰再显色，L 的恒定性完全失效。
- 深色模式适配中，仅调 L（如从
62%→38%）就能保色相不漂移，但前提是整套 token 全部用oklch()定义，且 H 值严格对齐 - 禁用态不能只降 L：那样会让按钮变暗又变灰，正确做法是固定 H、微调 L（±0.02），大幅降低 C（如
0.28→0.12） - 灰色系必须用
oklch(L 0 H)构建（H可任选，推荐240或0），而非gray()或hsl(0, 0%, L)，后者在 Safari 中仍不可靠
如何定义可维护的 OKLCH 设计 Token
CSS 自定义属性是唯一靠谱的落地方式，但必须规避两个高危陷阱：参数单位不统一、跨色彩空间引用。
- 所有
--color-primary、--color-secondary等变量必须用oklch(L C H)格式，L 统一用百分比（60%），C 用无单位小数（0.28），H 不带deg（258.5） - 禁止在同一个
:root中混写--c1: oklch(60% 0.28 240); --c2: hsl(240, 100%, 50%)，否则color-mix(in oklab, var(--c1), var(--c2))会静默失败 - 色阶生成建议用工具导出（如 colorjs.io），不要手动推算 a/b 值；例如
oklch(60% 0.28 240)→oklch(60% 0.12 240)是安全的饱和度衰减，而改a/b值极易导致色相塌陷
@supports + fallback 结构必须外置且顺序固定
OKLCH 声明一旦写错单位（如 L 缺 %、C 写成 28%），整条规则会被浏览器静默跳过——不是报错，也不是降级，而是彻底消失。这意味着如果你把 fallback 写在 @supports 块里，旧环境可能连基础色都看不到。
立即学习“前端免费学习笔记（深入）”；
- 正确结构：先写
background-color: #2563eb;，再写@supports (color: oklch(0% 0 0)) { ... }，顺序颠倒会导致部分安卓 WebView 忽略整个块 -
@supports检测值必须带单位：oklch(0% 0 0)✅，oklch(0 0 0)❌（所有主流浏览器返回 false） - 绝对禁用
@supports not：安卓 WebView 存在解析 bug，可能崩溃整段 CSS
渐变与动画中维持 L 恒定的实操红线
OKLCH 渐变天然支持 L 锚定，但浏览器不做短弧插值优化，稍有不慎就会在色相交界处引入灰带。
- 水平/垂直渐变中，若起止色相角差 > 180°（如
350° → 10°），必须手动拆成三段：oklch(0.7 0.25 350)→oklch(0.7 0.25 0)→oklch(0.7 0.25 10)，否则中间会经过低 C 的紫灰区 - 悬停动画中，禁止同时动 L 和 H：比如
oklch(60% 0.28 240)→oklch(65% 0.28 250)，L 和 H 耦合变化会破坏感知均匀性；应分步控制——先稳 L，再调 H；或先稳 H，再调 C - 宽色域增强（
@media (color-gamut: p3)）中，只提升 C（如0.28→0.38），L 和 H 必须保持不变，否则会破坏亮度一致性
真正难的不是写出 oklch(60% 0.28 240)，而是确保它在整个系统里不被任何一处混用、错位、漏检测所污染——L 恒定的前提，是整条渲染链路都拒绝妥协。
