LCH不是物理光感模型，而是CIELAB的极坐标变体，仅优化人眼感知均匀性；它不建模光谱功率分布、BRDF或光照，浏览器仍走sRGB管线，CSS亦无光谱维度支持。
LCH 模式本身不能“精确模拟物理世界的颜色光感”——它只是比 sRGB 更均匀的感知色空间，而“物理光感”需要结合光谱数据、BRDF、光照模型等，CSS 目前完全不支持。
为什么 LCH 不等于物理光感
LCH 是 CIELAB 的极坐标变体（L* 表示明度，C* 表示彩度，H° 表示色调），设计目标是让数值变化更贴近人眼感知差异，不是对光谱功率分布（SPD）或辐射度量的建模。浏览器渲染时仍走 sRGB 伽马管线，color(display-p3) 或 color(rec2020) 才涉及更广色域，但依然无光谱维度。
- 物理光感需描述光源光谱、物体反射率曲线、观察者视锥响应 —— CSS 里连单波长
hsl(540deg 100% 50%)都非法（超出可见光范围） -
lch()函数在 Chrome 111+ / Safari 16.4+ 支持，但输入值被 clamped 到 display-p3 色域内，超出部分静默降级 - 所谓“更真实”，仅体现在：相同 ΔL 和 ΔC 下，视觉差别更接近一致（比如调灰阶时不易出现“中间段发闷”）
怎样用好 lch() 做可感知的明度/彩度控制
真正实用的场景是 UI 中需要保持文本可读性、按钮状态对比、或跨色相统一灰阶。这时 L* 比 hsl() 的 lightness 可靠得多。
- 避免直接写
lch(50% 80 240)：百分号只对L*有效，C*和H°必须用绝对数值（Chrome 会报Invalid property value） - 明度校准推荐用
L*: 30–90区间，L*: 0和L*: 100在多数显示器上实际不可达（纯黑/纯白受背光限制） - 同一
L*下，不同色相的可读性仍不同（如蓝底黄字 vs 红底黄字），需实测 WCAG 对比度，别信“L=60 就安全” - 示例：让所有主按钮 hover 状态提升明度但不偏色：
button:hover { background-color: lch(75 60 280); }
和 oklch() 的关键区别在哪
oklch() 是 CSS Color Level 4 提案中更新的版本，基于 OKLab 均匀色空间，目前仅 Safari 16.4+ 和 Chrome Canary（需 flag）支持。它修正了 LAB 在蓝紫色区域的非线性问题。
-
lch()的H°在 270–330°（紫到红）过渡有“打结”现象：小角度变化导致大视觉跳跃 -
oklch()的H°是真正圆周连续的，插值更平滑（比如@keyframes中循环色相动画） - 两者
L含义不同：lch()的L*是 CIE 1976 明度，oklch()的L是 OKLab 的线性亮度分量，数值不可直接互换 - 当前生产环境建议用
lch()+fallback：color: hsl(240 100% 50%);<br>color: lch(54 70 250);
真正逼近物理光感的方向不在 CSS 颜色函数里，而在 WebGPU 渲染管线中接入 SPD 查表或使用 ACEScg 工作流 —— 但那已脱离样式层范畴。现阶段用好 lch() 的唯一务实目标，是让设计师调出的灰阶，在不同色相下看起来“真的差不多亮”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
