OKLCH能解决黄蓝明度差异问题，但需重校准整套参数逻辑：HSL的L值脱离人眼响应，而OKLCH的L是CIE 2002感知标度；单位错误、@supports顺序错或混用色彩函数均导致降级失效。
OKLCH 能直接解决黄蓝明度差异问题，但前提是别把 HSL 经验套过来——它不是“换个函数名就行”，而是整套参数逻辑都要重校准。
为什么 hsl(60, 100%, 50%) 和 hsl(240, 100%, 50%) 在视觉上亮度差三倍
HSL 的 L 是 RGB 极值的算术平均，完全脱离人眼响应：纯黄（hsl(60, 100%, 50%)）在 CIE Y 明度坐标中约 0.93，而纯蓝（hsl(240, 100%, 50%)）仅约 0.07。你调同一个 L 值，实际感知亮度根本不在一个量级。
-
oklch(0.5 0.32 60)和oklch(0.5 0.32 240)才真正对应同等视觉明度 - 这个
0.5是 OKLab 空间中经 CIE 2002 校正的感知标度，0 = 黑，1 = 白，与色相无关 - 别试图用
hsl()数值直接替换——必须用支持白点标注的转换器重采样（如 colorjs.io），输入#eab308→ 输出oklch(0.78 0.22 90.2)
写错一个单位，黄色就变灰、蓝色就消失
oklch() 不报错，只静默跳过整条声明。黄/蓝这类高对比色对单位错误尤其敏感，因为它们本就处在 sRGB 色域边缘。
-
oklch(78 0.22 90.2)❌ ——L缺 %，Chrome/Safari 直接忽略，fallback 到rgb()后颜色发闷 -
oklch(78% 22% 90.2)❌ ——C写成百分比，C 值被截断为 1，黄色瞬间失饱和、蓝变灰紫 -
oklch(78% 0.22 90.2deg)❌ —— Safari 16.x 解析失败，蓝按钮变透明 - 安全写法只有：
oklch(78% 0.22 90.2)（兼容性最高）或oklch(0.78 0.22 90.2)（仅新浏览器，H 小数位 ≤1）
@supports 检测错顺序，整个调色板在安卓 WebView 上全失效
很多团队只加两行颜色声明，结果在部分安卓设备上黄蓝按钮全变黑——不是 OKLCH 不支持，是降级结构没兜住。
立即学习“前端免费学习笔记（深入）”；
- 必须把 fallback 写在
@supports块**外部且上方**：color: #eab308;→ 然后才是@supports (color: oklch(0% 0 0)) { color: oklch(78% 0.22 90.2); } - 检测值必须带单位：
@supports (color: oklch(0% 0 0))✅，@supports (color: oklch(0 0 0))❌（所有主流浏览器拒斥） - 绝对禁用
@supports not—— 某些 WebView 解析时直接崩溃整段 CSS 规则 - 渐变里混用
hsl()或rgb()？浏览器立刻 fallback 到 sRGB 插值，黄蓝过渡中间必出一坨灰
深色模式下黄色不能简单降 L，蓝色也不能硬拉 C
OKLCH 的优势是解耦，但黄蓝对 L/C 变化的响应非线性程度不同：黄色在低 L 区易发暗塌缩，蓝色在低 C 区易偏品。
- 黄色主色
oklch(78% 0.22 90.2)进深色模式，建议改为oklch(32% 0.22 90.2)（只调 L，C 保持），而非降到20%—— 否则在 OLED 屏上文字边缘发虚 - 蓝色主色
oklch(54% 0.32 240)做禁用态，应降 C 至0.12，L 最多微调 ±0.02；若同步降 L 到40%，蓝会明显偏青，WCAG 对比度实测可能跌破 3.0:1 - 所有状态（hover/disabled/dark）必须统一用
oklch()，哪怕只是改一个参数 —— 混用即触发 sRGB 插值，感知一致性归零
最常被忽略的一点：OKLCH 的 L 值不是线性标尺。从 0.78 → 0.32 看似减了一半，实际感知明度变化远超比例，必须用 Chrome DevTools 的「Contrast」面板实测验证，不能靠数值估算。
