lch()函数仅在Chrome 111+、Firefox 117+、Safari 16.4+中可解析，但需严格匹配版本、单位（L和C必须带%、H必须带deg）及降级结构，否则整条声明静默失效，不报错也不回退。
直接用 lch() 写颜色，浏览器不报错但大概率静默失效——它不是“开了就能用”的功能，而是需要严格匹配版本、单位、降级结构的感知建模工具。
哪些浏览器真能解析 lch() 函数
lch() 在 Chrome 111+、Firefox 117+、Safari 16.4+ 中可识别，但行为差异明显：
- Firefox 117+ 支持基础
lch()，但color-mix(in lch, ...)要等到 Firefox 120+ 才稳定 - Safari 16.4–17.3 对
lch(70% 80 240deg)解析宽松，但遇到lch(70 80 240)（L 缺 %）会整条跳过 - Chrome 111+ 会自动 clamp 超出 sRGB 色域的值（如
lch(50% 150 240)→ 渲染为近似灰阶），而 Safari 可能显示异常或透明 - 所有安卓 WebView（包括 Chrome for Android 旧版）基本不支持，
@supports (color: lch(0% 0 0))检测在多数 WebView 中返回 false
lch() 参数单位写错一个，整条声明就消失
这不是警告，是真实发生的行为：浏览器不会提示、不 fallback 到下一条，直接忽略该行 CSS。
-
lch(70% 80 240)❌ —— C 缺单位（必须是80或80%，但不能无单位混用） -
lch(70 80 240deg)❌ —— L 缺 %（70不合法，70%或0.7才行） -
lch(70% 80% 240deg)✅ —— 单位显式、顺序固定（L → C → H），H 必须带deg - L 是 CIE Lightness，0% = 黑，100% = 白；L=0% 或 100% 时 C 强制归零，
lch(0% 100 240)渲染为纯黑，不是“暗蓝”
为什么 lch() 的 L 值比 hsl() 更均匀，但不能直接替换
lch() 的 L 直接映射 CIE L*a*b* 明度轴，ΔL ≈ Δ感知亮度差；而 hsl() 的 lightness 是 RGB 极值平均，同值下黄、蓝的实际 CIE Y 亮度可差 10 倍。
立即学习“前端免费学习笔记（深入）”；
- 做深色模式时，
hsl(240, 100%, 20%)在 #121212 上几乎不可见（Y≈0.01），lch(25% 60 240)才真正落在“视觉暗度一致”的档位 - 但设计师给的 LCH 值常来自 Figma（D50 白点），CSS 使用 D65，青绿区色相偏移 3–5°，需用专业工具校准，不能照搬
- 渐变中跨 0°/360° 插值（如
lch(60% 70 350deg)→lch(60% 70 10deg)）不会走短弧，中间段会塌陷成灰带 -
color-mix(in lch, ...)是当前最稳妥的混合方式，但两个输入必须都是lch()，且百分比单位不能省：lch(60% 70 240deg)✅，lch(60 70 240deg)❌
调试 lch() 时最常被忽略的三件事
DevTools 不显示真实 LCH 值，复制出来的永远是降级后的 sRGB 十六进制，靠它验证等于白忙。
- 想确认是否生效，只能肉眼比对：同一页面并排渲染
lch(60% 70 240deg)和hsl(240, 100%, 60%)，看蓝调是否更稳、不发灰 - 自定义属性存不了 LCH 语义：
--c1: lch(60% 70 240deg)对浏览器无意义，JS 读取getComputedStyle(el).backgroundColor返回的仍是 sRGB - 动画和 transition 无法保留 LCH 空间插值：
--primary: lch(60% 70 240deg); --hover: lch(75% 70 240deg); transition: background 0.3s;实际走的是 sRGB 线性插值，失去均匀性优势
