OKLCH用感知均匀的OKLab空间替代HSL，其L值真实对应人眼明暗响应，而HSL的L仅是RGB极值平均、视觉亮度不一致；oklch()中L必须为0–1或0%–100%，单位不可省略，且与HSL数值不可直接换算。
OKLCH 不是为“修复 HSL 的亮度问题”而生的，而是用更科学的感知模型替代了 HSL 这种基于 RGB 立方体切割的、非均匀的色彩表示法。HSL 的 L（Lightness）在不同色相下明暗感知不一致，根本原因在于它没建模人眼——OKLCH 的 L 才真正对应人眼对明暗的响应。
oklch() 的 L 为什么比 hsl() 的 L 更可靠
HSL 的 L 是 RGB 三通道最大值与最小值的平均值，数学上简洁，但和视觉明暗脱节：比如 hsl(0, 100%, 50%)（纯红）和 hsl(120, 100%, 50%)（纯绿）在屏幕上看起来亮度差很多，前者明显更刺眼；而 oklch(0.5 0.32 0) 和 oklch(0.5 0.32 120) 的 L 都是 0.5，实际感知亮度才真正接近。
- HSL 的 L=50% 对红/绿/蓝三色，输出的 sRGB 值分别是
#ff0000、#00ff00、#0000ff，Y（CIE luminance）值分别为 ~0.21、~0.72、~0.07 —— 差距巨大 - OKLCH 的 L=0.5 是 OKLab 空间中的感知亮度坐标，经过非线性压缩，让 0.5 在所有色相下都落在人眼敏感度中段
- 深色模式下尤其明显：调
hsl(240, 100%, 20%)得到的是一种发灰的暗蓝，而oklch(0.2 0.25 240)能稳稳维持蓝调+足够辨识度
浏览器怎么解析 oklch() 和 hsl() 的 L 参数
两者语法相似，但语义完全不同，且单位容忍度差异大：
-
hsl()的 L 接受50或50%，等价；oklch()的 L 必须带单位（0.5或50%），oklch(50 0.2 240)直接失效（被忽略） -
hsl()的 L 范围是 0–100（百分比），oklch()的 L 是 0–1（小数）或 0%–100%，二者数值不能直接换算——hsl(240, 100%, 50%)≈oklch(0.54 0.32 240)，不是oklch(0.5 ...) - Chrome DevTools 在 computed 样式里永远只显示降级后的 sRGB 值，看不到真实 OKLCH 行为，调试时必须靠视觉比对或 JS 读取
getComputedStyle后再人工验证
跨色相调色时 oklch() 如何避免 HSL 的“色相塌陷”
HSL 在高饱和下做色相过渡（比如从红到紫），经常出现中间段发灰、断层、甚至跳变，因为 a/b 轴在 CIELAB 中有压缩区；OKLCH 基于 OKLab，在全色相范围内色度 C 的扩展更平滑：
立即学习“前端免费学习笔记（深入）”；
- 写渐变时，
linear-gradient(oklch(0.6 0.25 0), oklch(0.6 0.25 300))比linear-gradient(hsl(0, 100%, 60%), hsl(300, 100%, 60%))更少出现意外灰带 - 但要注意：OKLCH 仍不自动处理 0°/360° 边界，
oklch(0.6 0.25 350)→oklch(0.6 0.25 10)会绕远，应手动拆成两段或改用color-mix(in oklch, ...) - 日常使用建议把 C 控制在 ≤0.28，既能避开多数设备的色域 clamp，又能保证各色相下亮度稳定性
真正难的不是写对 oklch() 语法，而是放弃“L=50% 就该是中间灰”的直觉——OKLCH 的 L 是感知标尺，不是数值标尺；你得先校准眼睛，再调参数。
