为什么CSS的oklch更适合做设计系统

OKLCH是设计系统中唯一能实现亮度锚定、色相独立调节、禁用态与深色模式策略解耦的颜色模型；其L值为感知校正的无量纲标度（须带%），同一L下各色视觉亮度一致，且需正确书写单位、配好降级、避开插值陷阱。

OKLCH 不是“更适合”，它是设计系统中唯一能真正实现亮度锚定、色相独立调节、禁用态与深色模式策略解耦的颜色模型——前提是写对单位、配好降级、避开插值陷阱。

oklch() 的 L 值为什么能当设计系统的亮度锚点

因为 OKLCH 的 L 是 CIE 2002 感知校正后的无量纲标度，不是 RGB 极值平均。同一 L=62% 下，蓝（258.5）、橙（35）、绿（120）在人眼看来明暗一致；而 HSL 的 lightness: 62% 对这三色实际亮度差可达 2–3 倍。设计系统里所有主色、强调色、状态色只要共享一个 L 值，就能天然保持视觉重量平衡。

1. L 必须带 %（如 62%），写成 0.62 或 62 在 Safari 17.4 以下全静默失效
2. 不能直接套用品牌 HSL 值：比如 hsl(240, 70%, 50%) ≠ oklch(50% 0.28 240)，得用转换器重采样（实测接近 oklch(54% 0.32 240)）
3. 灰色系必须用 oklch(L 0 H) 构建，而不是 gray()——后者在 Safari 中仍部分不可用

@supports 检测写错就整个主题链断掉

OKLCH 不报错、不警告，写错就跳过整条声明。设计系统一旦漏掉降级或检测条件错位，轻则按钮变黑，重则文字在浅底上完全不可读。

1. 降级色必须写在 @supports 块**外部且上方**：background-color: #2563eb; → 再写 @supports (color: oklch(0% 0 0)) { ... }
2. 检测值必须带单位：@supports (color: oklch(0% 0 0)) ✅，@supports (color: oklch(0 0 0)) ❌（Safari 17.4+ 也返回 false）
3. 绝对不要用 @supports not——安卓 WebView 有解析 bug；也别用 oklab() 检测，所有主流浏览器目前都返回 false

渐变和禁用态必须用不同参数逻辑

设计系统里渐变按钮、悬停态、禁用态的调参逻辑不能混用。OKLCH 的价值恰恰在于它强制你把每种语义拆开：深色模式只动 L，禁用态只压 C，色环组件只扫 H。

1. 深色模式适配：oklch(62% 0.28 258.5) → oklch(38% 0.28 258.5)（固定 C 和 H，只降 L）
2. 禁用态设计：oklch(62% 0.28 258.5) → oklch(62% 0.12 258.5)（固定 L 和 H，只降 C，避免浅底上文字突然消失）
3. 色相跨 0°/360° 渐变（如 350° → 10°）必须手动拆段：linear-gradient(oklch(0.7 0.25 350), oklch(0.7 0.25 0), oklch(0.7 0.25 10))，否则中间出灰紫带

最难的不是写出 OKLCH 值，而是确保它在 UnoCSS 构建流程里不被压缩丢空格、在 Safari 16.x 里不因 deg 后缀解析失败、在安卓 WebView 中不因 @supports not 整块失效——设计系统越复杂，这些边界条件越容易被忽略。