lch()不是RGB升级版，而是基于CIELAB的感知导向坐标系：L为感知明度（0–100），C为色度（饱和度强度），H为色相角（0–360°），三者正交且设备无关，调L不偏色、调H不改变亮度，支持广色域显示。
lch() 不是 RGB 的“升级版”，而是另一套坐标系
RGB 描述的是显示器怎么发光：三个通道分别控制红、绿、蓝子像素的强度（0–255），本质是加色模型的物理实现。lch() 则完全不碰设备通道，它基于 CIELAB 空间，把颜色表达为 L（明度）、C（色度）、H（色相）——这三个值对应人眼感知维度，不是硬件驱动信号。
调 L 值时，RGB 会偏色，lch() 才真“只调亮暗”
在 rgb(255, 0, 0)（纯红）上改亮度，你只能靠降低所有通道或叠加黑/白层，结果要么发灰、要么失饱和；而 lch(60% 85 20) 调成 lch(40% 85 20)，色相和鲜艳度保持不变，只是视觉变暗——因为 L 是 CIE 定义的感知明度标尺，不是 RGB 极值平均值。
-
hsl(0, 100%, 50%)和hsl(120, 100%, 50%)的视觉亮度差三倍，但lch(50% 70 0)与lch(50% 70 120)在同一显示器上才真正等亮 - RGB 没有统一的“亮度轴”，
L在 lch() 中是独立且感知线性的，前提是显示器支持对应色域（如 P3）
浏览器解析 lch() 时会静默降级，RGB 不会
写 color: rgb(100, 180, 255); color: lch(70% 85 250);，旧版 Safari（如 15.x）遇到不识别的 lch() 会直接丢弃整条声明，回退到继承色或透明——不是变灰，是“消失”。而 rgb() 全版本兼容，无任何风险。
- 必须前置声明 fallback：
background-color: rgb(100, 180, 255); background-color: lch(70% 85 250); -
@supports (color: lch(0 0 0))在部分 Safari 版本中误报，不能依赖它做关键路径的颜色切换 - PostCSS 自动转译已不可靠，
lch()的色相圆周逻辑（如 355°→5°）需手动拆段，工具无法智能处理
色域覆盖能力根本不在一个量级
rgb() 固定绑死 sRGB 色域，再高的数值也会被 clamp 到边缘；lch() 可激活 DCI-P3 或 Adobe RGB 显示器上的高饱和青绿、洋红区域——比如 lch(60% 125 160) 在 MacBook Pro 上呈现的青色，远超 hsl(160, 100%, 50%) 或任何 rgb() 组合所能表达的鲜活度。
立即学习“前端免费学习笔记（深入）”；
- 但别盲目拉高
C：LCD 屏幕在L=50–70区间，C > 110就容易 banding；OLED 可试到 130，仍需真机验证 -
L=0%或L=100%时，C强制归零——这和hsl(160, 100%, 0%)还保留色相语义完全不同 - Figma 默认用 D50 白点，而 CSS
lch()解析用 D65，青绿区间色相偏移 3–5°，rgb()和hsl()无此问题
