统一L值是OKLCH调色板感知均匀的前提，因L代表感知亮度而非RGB算术平均，实测HSL同L值颜色亮度差异可达三倍以上，而OKLCH同L值才真正视觉等亮。
直接用 oklch() 定义调色板，L 值统一、C 值按色相微调、H 固定不乱动，才能真正实现视觉亮度一致——这不是调色技巧，而是 OKLCH 空间本身的数学特性决定的。
为什么统一 L 值是调色板感知均匀的前提
HSL 的 l 是 RGB 极值的算术平均，和人眼无关；OKLCH 的 L 是 OKLab 中的感知亮度坐标。实测：hsl(0, 100%, 50%)（纯红）CIE Y 亮度约 0.21，hsl(120, 100%, 50%)（纯绿）约 0.72，差三倍以上。而 oklch(60% 0.28 0) 和 oklch(60% 0.28 120) 在人眼看来才是“一样亮”的。
- 多色组件（如标签页、状态徽章）若用 HSL，绿色总抢眼、蓝色总发灰，根源就是 L 不感知均匀
- 深色模式下统一把 HSL 的
l减 30%，结果红色按钮糊成一片，青色图标却刺眼——因为减的是数学值，不是感知值 -
L必须带%单位，写成oklch(60 0.28 0)或oklch(0.6 0.28 0)（旧 Safari 不认）会被所有主流浏览器静默忽略
如何为不同色相安全设置 C 值
OKLCH 色域不是均匀的：同个 C=0.28，在蓝色区饱满，在黄色区可能已超限被 clamp 成灰阶。日常品牌系统中，C 控制在 ≤0.28 是兼顾表现力与跨设备一致性的安全线。
- 优先试蓝（
H≈240–270）和紫（H≈270–300），它们的 C 上限高（可达 0.35+） - 避免在黄（
H≈40–60）和青（H≈160–190）硬拉 C；红橙区 C 超过 0.22 就容易发棕 - 同一调色板内，若主色用
oklch(62% 0.28 258.5)，辅助色建议保持 H 差 ±30° 内，C 同步微调 ±0.03，而非强行拉到相同 C
@supports 检测必须写对位置和写法
OKLCH 不支持时不是报错，而是整条声明被跳过。如果 fallback 写错位置或检测值单位不对，UI 就直接变透明、变黑或错色。
立即学习“前端免费学习笔记（深入）”；
- 降级色（如
rgb(37, 99, 235)或#2563eb）必须写在@supports块外部且上方 - 检测只能用
@supports (color: oklch(0% 0 0))，不能用oklab()或not否定式（安卓 WebView 解析失败） - 检测值里的
0%必须带单位，写成oklch(0 0 0)会导致检测永远返回 false - 别把整个调色板规则包进
@supports块里——只包裹 OKLCH 专属部分，比如禁用态规则、深色模式变体
渐变与动画中避免跨 0/360 色相插值
浏览器不会自动为 OKLCH 渐变选短弧。从 oklch(0.7 0.25 350) 到 oklch(0.7 0.25 10)，会经过 350→360→0→10，中间出现大片灰带。
- 色相差 >180° 时，必须手动拆段：
linear-gradient(oklch(0.7 0.25 350), oklch(0.7 0.25 360), oklch(0.7 0.25 10)) - 禁用态不要靠
opacity模拟——它破坏 OKLCH 的感知一致性；应固定 H，只降 C（如 0.28 → 0.12），L 最多微调 ±0.02 - 深色模式变体只调 L（如 0.62 → 0.38），H 和 C 保持不变；否则夜间对比度失控
- DevTools 里看不到真实 OKLCH 值，复制出的永远是 sRGB 降级结果；验证只能靠视觉比对 + 限制 C 上限
最易被忽略的是：OKLCH 的 L 值必须全程统一，哪怕只是做一组中性灰——oklch(20% 0 0)、oklch(40% 0 0)、oklch(60% 0 0) 才是真等距；混一个 rgb(100, 100, 100) 进来，整套就失效。
