OKLCH 不能直接解决黄色刺眼问题，但通过感知一致的 L（亮度）与 C（色度）分离控制，可精准避免过亮：HSL 的 L 是数学平均值，而 OKLCH 的 L 基于人眼感知，同 L 值下黄、红视觉明度一致；实测 hsl(60,100%,90%) 已刺眼，oklch(0.78 0.25 90) 则柔和舒适；UI 黄色推荐 L 控制在 0.70–0.78（浅色）或 0.40–0.52（深色），C 保持 0.18–0.23，h 不加 deg，L 必须带 %，且渐变需拆段防灰带。
OKLCH 本身不能“解决”黄色过亮刺眼的问题，但它提供了真正可控的亮度（L）和色度（C）分离能力——只要你不把 L 设成 0.95 这种高亮值，黄色就不会刺眼；而用 HSL 调黄，L: 95% 看似合理，实际在人眼感知里已远超舒适阈值。
为什么HSL里的“亮黄”在OKLCH里会暴露真实亮度
HSL 的 L 是 RGB 三通道极值的算术平均，对黄色（hsl(60, 100%, 95%)）来说，它混合了高红、高绿、低蓝，数学上很亮，但人眼对黄光特别敏感，实际感知亮度远高于数值。OKLCH 的 L 是 OKLab 感知亮度坐标，oklch(0.85 0.25 90) 和 oklch(0.85 0.25 0)（红）在屏幕上看起来才真正“一样亮”。
- 实测对比：
hsl(60, 100%, 90%)在多数屏上已明显发白刺眼；oklch(0.78 0.25 90)同样视觉明度，但柔和不眩目 -
L值超过0.82的暖色（黄/橙）就容易触发瞳孔收缩反应，建议日常 UI 黄色控制在0.70–0.78区间 - 别信“
L: 80%应该刚好”，OKLCH 中0.80≈ HSL 的72–75%感知亮度，不是数值对等
用OKLCH调黄必须守住三个参数底线
写错任意一个单位，整条声明静默失效，页面直接回退到 fallback 色——你以为调暗了，其实浏览器根本没读到新颜色。
-
L必须带%：用oklch(75% 0.22 90)，别写oklch(0.75 0.22 90)（Chrome 112+ 支持但 Safari 17.4+ 仍不稳定） -
C必须是无单位小数：黄色饱和度别拉太高，C > 0.25容易偏荧光感，推荐0.18–0.23 -
h别加deg：写90，不是90deg；小数位最多留一位（90.5可，90.54在部分 Safari 版本里解析失败）
深色模式下黄色更需独立控L，不能靠自动反转
很多深色主题直接把浅色模式的 oklch(0.75 0.22 90) 改成 oklch(0.35 0.22 90)，结果黄色变脏、发绿——因为 OKLCH 的 L 是感知亮度，不是线性光值，从 0.75 降到 0.35 不是“减半”，而是跨过视觉敏感区，需要重新校准。
- 深色背景上，黄色舒适
L区间是0.40–0.52，比浅底下降幅度更小（不是同比例缩放） - 禁用态不要只降
L：改用oklch(0.48 0.12 90)—— 固定h，小幅降C，保色相不偏，同时避免因亮度骤降导致对比度跌破 4.5:1 - 测试时关掉系统深色模式，手动在 DevTools 里切
@media (prefers-color-scheme: dark)，确认 fallback 色没被意外覆盖
渐变中黄→其他色最容易出灰带，必须拆段
黄色（h ≈ 90）到蓝色（h ≈ 240）色相差 150°，看似安全，但 CSS 渐变引擎仍可能走长弧路径，中间插入大量低 C 的灰黄/灰绿，破坏过渡自然性。
- 不要写：
linear-gradient(to right, oklch(0.75 0.22 90), oklch(0.55 0.25 240)) - 要拆成两段：
linear-gradient(to right, oklch(0.75 0.22 90), oklch(0.65 0.23 165), oklch(0.55 0.25 240))，中间补一个感知中位色 - 如果涉及跨 0°/360°（比如黄→品红），色相差 >180° 时强制拆三段：
oklch(0.75 0.22 90) → oklch(0.75 0.22 0) → oklch(0.75 0.22 330)
最常被忽略的是：OKLCH 的优势不在“颜色多好看”，而在“调哪个轴就只动那个轴”。黄色刺眼，从来不是色相问题，是亮度和色度耦合失控的结果——你得先承认 HSL 的 L 是假亮度，才能真正用好 OKLCH 的 L。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
