推荐用 oklch() 而非 hsl()，因其 L 值基于 CIE 2002 感知模型，同 L 真正视觉等亮；hsl() 的 L 是 RGB 极值算术平均，调 L 必偏色，且渐变、单位、fallback 等细节极易出错导致 UI 失效。
做 UI 组件库时，CSS 推荐用 oklch() 而不是传统 hsl()，核心就一条：组件库要批量生成、统一调控、跨模式复用颜色，而 hsl() 的 L 值根本做不到“调 L 不偏色”——它只是 RGB 极值的算术平均，同一 L=50% 下纯红和纯绿在人眼看来亮度差三倍；oklch() 的 L 是 CIE 2002 感知模型校正过的，同 L 才真正在所有色相下“看起来一样亮”。
为什么 hsl() 的 L 值在组件库里会失控
hsl() 的 L 是数学构造，不是感知锚点。比如按钮主色用 hsl(240, 100%, 50%)（蓝），禁用态想降亮度，写成 hsl(240, 100%, 30%)，结果蓝变灰紫；深色模式下调到 hsl(240, 100%, 20%)，又发青发黑——这不是设计意图，是模型缺陷。
- 同一
L值在不同色相下视觉明度不一致，组件库无法靠统一L建立文字/背景/边框的可读性层级 - 悬停态用
lighten()或darken()函数，本质仍是 sRGB 插值，蓝→紫→灰的断层在小屏上极明显 - 品牌色扩展（如 --primary-100 到 --primary-900）靠手调或 Sass 函数生成，
hsl()下越调越失饱和、越调越偏色
@supports 降级结构写错，整套组件直接失效
oklch() 不支持时浏览器不会报错，而是静默跳过整条声明。如果组件库里把 fallback 写进 @supports 块内部，或者检测值漏了 %，用户看到的就是透明背景、继承色文字，或全黑块——尤其在安卓 WebView 中，@supports not 会被整块丢弃。
- 降级色必须写在
@supports块**外部且上方**：background-color: #2563eb;→ 再跟@supports (color: oklch(0% 0 0)) { ... } - 检测值必须带单位：
@supports (color: oklch(0% 0 0))✅，@supports (color: oklch(0 0 0))❌（Safari/Chrome/Firefox 全部返回 false） - 别用
oklab()检测——目前所有主流浏览器都返回 false，连实验性支持都没有
渐变与悬停态中色相跨 0° 边界必须手动拆段
CSS 对 oklch() 渐变不做色相短弧插值。写 linear-gradient(oklch(0.7 0.25 350), oklch(0.7 0.25 10))，浏览器按数值走 350 → 360 → 10，中间段彩度被强制压缩，出现灰紫色带——这在按钮悬停、加载动画、状态指示器里一用就露馅。
立即学习“前端免费学习笔记（深入）”；
- 色相差超过 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 插值，前功尽弃 - 移动端长按/滑动时这类断层更敏感，OLED 小屏上灰紫带比桌面端更刺眼
L 和 C 必须严格带单位，错一个 % 就整行静默忽略
oklch(60% 0.28 258.5) ✅，oklch(60 0.28 258.5) ❌（所有浏览器静默忽略），oklch(0.6 0.28 258.5) 仅 Chrome 112+/Firefox 121+/Safari 17.4+ 支持，不够稳妥。
-
L必须带%或小数，但生产环境建议统一用60%—— 兼容性兜底 -
C必须是无单位小数（如0.28），写成28%或28会被忽略 -
H单位只能是纯数字，加deg在 Safari 16.x 和部分安卓 WebView 中解析失败 - alpha 必须用
/分隔：oklch(60% 0.28 258.5 / 0.8)✅，逗号写法 ❌
最常被忽略的不是“怎么写”，而是单位细节和 fallback 顺序——错一个 %，整行 CSS 就像没写过；降级色位置一错，UI 就在旧设备上彻底不可用。组件库不是单页 Demo，它得扛住真实终端碎片化。
