OKLCH能解决HSL黄色明度过高刺眼的问题，因其L基于人眼感知亮度而非数学平均值，使同L值下各色相视觉明暗一致，避免黄色过亮、蓝色过暗的失衡现象。
OKLCH 能解决 HSL 黄色明度过高刺眼的问题，根本原因在于：HSL 的 L 是数学平均值，而 OKLCH 的 L 是人眼感知亮度——同一 L 值下，黄色不再比蓝色亮三倍，视觉明暗真正一致。
为什么 hsl(60, 100%, 50%) 黄色在白底上刺眼？
HSL 的 L 完全脱离人眼响应：它只是 max(R,G,B) 和 min(R,G,B) 的算术平均。实测 hsl(60, 100%, 50%)（纯黄）在 CIE Y 空间亮度约 0.93，而 hsl(240, 100%, 50%)（纯蓝）仅约 0.07。同为“50% 明度”，黄色实际接近纯白，贴着文字可读性边界疯狂试探，一不留神就眩光。
这不是参数调得不够细，是空间建模错了——你没法靠“把黄的 L 调到 30%”来救，因为那会同时压垮饱和度，黄变灰；更没法统一用这个 L 值去配蓝、紫、青，它们的视觉明暗根本不在线上。
-
hsl(60, 100%, 50%)→ 实际太亮，常需手动降到hsl(60, 100%, 30%)才可用，但此时已偏橙、失饱和 - 所有其他色相都得各自找“安全 L”，无法批量生成阶梯色板
- 深色模式下，
hsl(60, 100%, 70%)可能直接糊进深灰背景里，对比度崩盘
oklch() 怎么让黄色“老实下来”？
OKLCH 的 L 来自 OKLab 空间，经 CIE 2002 色貌模型校正，锚定的是视锥细胞响应曲线。只要 L 相同，无论 H 是 60°（黄）还是 240°（蓝），人眼感知明暗就基本一致。
立即学习“前端免费学习笔记（深入）”；
比如品牌主色是黄：hsl(60, 100%, 50%) ≈ oklch(0.54 0.22 60)。这时你直接按 WCAG 对比度要求设 L = 0.93（极浅）、L = 0.12（极深），黄色自动落在舒适区，不刺眼也不发闷。
- 生成 50–950 色阶时，
LIGHTNESS_MAP[500] = 0.55对所有色相一视同仁，黄色不会突兀跳亮 - 深色模式只需
oklch(0.38 0.22 60)，黄调不变，明暗过渡平滑，不闪不跳 - 禁用态用
oklch(0.54 0.08 60)（只降C），黄依然清晰可辨，不因亮度骤变导致文字“沉底”
@supports 检测和单位写错，会让 OKLCH 彻底失效
OKLCH 不报错，只静默跳过整行 CSS。一旦失效，你的黄色就退回原始 hsl() 或 fallback 色，刺眼问题原样重现，还找不到报错提示。
-
@supports (color: oklch(0% 0 0))✅ 必须带%，@supports (color: oklch(0 0 0))❌ Safari 17.4+ 也返回false - 降级色必须写在
@supports块**外部且上方**：background-color: #fbbf24;→ 再写@supports块，否则某些安卓 WebView 直接忽略整块 -
oklch(50% 0.22 60)✅ 最稳妥；oklch(0.5 0.22 60)⚠️ 仅 Chrome 112+/Firefox 121+/Safari 17.4+ 支持，且H小数位超过 1 位（如60.123）可能在旧 Safari 解析失败
渐变中黄色跨色相时，别指望浏览器自动优化
写 linear-gradient(oklch(0.9 0.22 60), oklch(0.9 0.22 0))，浏览器按数值线性插值：60 → 0，没问题；但写 oklch(0.9 0.22 350) → oklch(0.9 0.22 10)（黄→黄，绕一圈），它真会走 350 → 360 → 10，中间经过 H=0° 时 C 被压缩，出现灰白带——黄色瞬间“脏了”。
- 色相差 >180° 时必须手动拆段：
linear-gradient(oklch(0.9 0.22 350), oklch(0.9 0.22 0), oklch(0.9 0.22 10)) - 所有节点必须统一用
oklch()，混rgb()或hsl()就 fallback 到 sRGB 插值，黄色又变回“数学亮” - DevTools 的 computed 面板永远只显示 fallback 后的十六进制值，真值只能靠肉眼比对 + 控制
C ≤ 0.22防溢出
真正难的不是把黄色写成 oklch()，而是整条链路——从主题变量定义、@supports 结构、渐变拆分，到禁用态/深色模式的参数分工——全部锚定在感知空间里。错一个点，黄色就回到刺眼的老路上。
