LCH不是未来标准而是专用工具：在深色模式、禁用态、多色组件中需视觉明暗一致时，其L值才真正可靠；HSL的lightness因是RGB极值平均，同数值下红黄蓝亮度偏差可达三倍，调色不可控。
LCH 不是“未来标准”，而是解决特定 UI 问题的专用工具——当你需要在深色模式、禁用态、多色组件间保持视觉明暗一致时，lch() 的 L 值才真正可信赖；HSL 的 lightness 在不同色相下视觉亮度偏差可达 30% 以上，靠它调色等于凭感觉押注。
为什么 lch() 的 L 值在 UI 中更可靠
HSL 的 lightness 是 RGB 三通道最大值与最小值的平均，纯数学构造，和人眼无关。实测：hsl(0, 100%, 50%)（红）CIE Y 亮度约 0.21，hsl(60, 100%, 50%)（黄）约 0.72，hsl(240, 100%, 50%)（蓝）约 0.07——同一数值，实际亮度差三倍。lch() 的 L 是 CIE Lightness（0% = 黑，100% = 白），在全色相范围内 ΔL ≈ 等感知亮度差。
-
L必须为 0–100 整数或百分比：lch(50% 80 240)合法，lch(0.5 0.8 240)无效（那是oklch()写法） -
L: 0%或L: 100%时，C强制归零——lch(0 80 240)直接变纯黑，而hsl(240, 100%, 0%)还保留色相语义 - 设计师给的 LCH 值大概率来自 Figma（D50 白点），但 CSS
lch()默认按 D65 解析，青绿区间色相偏移 3–5°，必须用支持 D50→D65 转换的工具校准
lch() 和 oklch() 到底怎么选
oklch() 基于 OKLab 空间，感知均匀性更强，尤其在中低亮度区间和蓝紫区域更稳定；lch() 基于 CIELAB，在青蓝色系插值时易显灰。但兼容性上，lch() 更早落地：Safari 16.4+、Chrome 111+、Firefox 117+ 支持；oklch() 需 Chrome 112+/Firefox 121+/Safari 17.4+。
- 做深色模式渐变、UI 色阶、无障碍对比度微调 → 优先选
oklch() - 需快速适配旧浏览器、或仅需基础感知亮度控制 →
lch()更稳妥 - 两者都不支持时，降级必须写在
@supports外部且上方：background-color: #2563eb;，再包裹@supports (color: lch(0% 0 0))
常见写错就静默失效的坑
浏览器不会报错，也不会 fallback 到下一条，它直接跳过整行声明——这是最常被忽略的致命点。
立即学习“前端免费学习笔记（深入）”；
-
lch(50 100 270)❌ 缺%，所有浏览器静默忽略 -
lch(50% 100% 270)❌C应为无单位数值（如 100），不是百分比 -
lch(50% 100 270deg)❌H后加deg在 Safari 16.x 和部分安卓 WebView 中解析失败 - 检测值必须带单位：
@supports (color: lch(0% 0 0))✅，@supports (color: lch(0 0 0))❌
真正卡住人的从来不是哪个模型“更先进”，而是你是否清楚：要调的是感知亮度，还是工程效率；是面向 P3 屏幕的高饱和青绿，还是兼容 iOS 15.6 的按钮悬停态——lch() 是把好刀，但得知道切哪块肉。
