lch不能直接用oklch转换公式，因二者底层空间不同：lch基于cielab（d65、srgb受限），oklch基于oklab（更均匀、色域更广）；混用会导致高饱和区严重偏色或溢出，正确转换须经lch→lab→xyz→srgb→hex全链，不可跳步。
lch() 颜色不能直接用浏览器原生 API 解析成 RGB，也没有内置的 lchToRgb 函数。你得自己实现转换逻辑，而且必须注意：LCH 是基于 CIELAB 的极坐标表示，不是线性空间，不能像 OKLCH 那样简单套用三角函数近似。
为什么不能直接用 OKLCH 的转换公式？
OKLCH 和 LCH 虽然结构相似（lch(l c h) / oklch(l c h)），但它们的底层色彩空间不同：
- lch() 基于 CIELAB（D65 白点，sRGB 色域受限）
- oklch() 基于 OKLAB（更均匀、更广色域、专为 CSS 设计）
直接复用 OKLCH 的 oklchToRgb 函数会严重偏色，尤其在高饱和区域（比如 lch(70% 120 280) 可能转出负值或溢出 RGB 范围）。
正确转换路径：LCH → LAB → XYZ → sRGB → HEX
标准转换链不可跳过，否则精度损失大、色差明显。关键步骤包括：
-
lch(l c h)→lab(l a b)：用a = c * cos(h * π / 180),b = c * sin(h * π / 180)（注意：LCH 的l是百分比，需先转为 0–100 数值） -
lab→xyz：需查表或使用反向 CIELAB 公式（涉及非线性立方根计算） -
xyz→srgb：矩阵变换 + gamma 压缩（if (c ） - 最后 clamp 到 [0, 255] 并转 HEX
推荐直接用成熟库如 color-space 或 nanocolor，它们已处理白点、gamma、clamping 等边界情况。自己手写容易漏掉 D65 白点归一化或 sRGB 转换中的 1.055 系数。
常见错误：忽略 LCH 的百分比和单位差异
输入字符串如 lch(65.4% 42.5 290.2)，注意：
-
l是百分比（65.4%→65.4），不是 0–1 小数 -
c和h无单位，但h是角度（0–360），不是弧度 - 正则提取别用
/(\d+\.\d+)/g——它会把65.4%提成65.4，但也会错提290.2deg（如果误带单位）；稳妥做法是匹配/lch\(([^)]+)\)/再按空格分割，再逐项 trim + 去 %
例如："lch(65.4% 42.5 290.2)".match(/lch\(([^)]+)\)/)[1].split(/\s+/) 得到 ["65.4%", "42.5", "290.2"]，再对第一项 .replace('%', '')。
性能与兼容性现实
纯前端做 LCH → HEX 转换开销不小（每调用一次要跑 3–4 层非线性计算），不适合高频场景（如实时调色器拖动）。如果只是静态颜色转换，建议：
- 构建时用 PostCSS 插件（如
postcss-color-function）预编译 - 服务端用 Python 的
colour-science库批量处理（精度更高） - 避免在
requestAnimationFrame中反复调用转换函数
真正容易被忽略的是：LCH 在旧版 Safari（getComputedStyle(el).color 返回的可能仍是 fallback 的 rgb()，而不是原始 lch() 字符串——这意味着你无法靠 JS 读取并转换用户设置的 LCH 值，除非你全程自己维护颜色状态。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
