浏览器默认在srgb空间线性插值，长路径色相变化必经低饱和灰区；hsl不自动选短弧，需手动拆段；oklch需密集停靠点（≤20%间隔）并统一格式，混用颜色或简写将强制回退srgb。
因为浏览器默认在 srgb 空间做线性插值，而长路径色相变化（比如从红到蓝、黄到紫）在该空间里必然穿过人眼敏感的低饱和中明度区域——这不是 bug，是数学结果。
in hsl 插值不等于“走短弧”，必须显式控制色相方向
in hsl 只表示用 HSL 坐标系插值，但不自动选最短色相路径。比如 hsl(350, 100%, 50%) → hsl(10, 100%, 50%)，浏览器可能按 350→360→10 插值（跨 20°），也可能按 350→0→10（跨 20°），看起来一样；但若写成 hsl(350, 100%, 50%) → hsl(190, 100%, 50%)，它就会老老实实走 350→360→0→...→190，中间经过一大段灰紫区。
- 想强制走短弧，得手动拆段：先到
hsl(0, 100%, 50%)，再到hsl(190, 100%, 50%) - 别依赖
hsl()函数自动“聪明”——它只管三个通道线性变化，H 通道本身仍是 0–360 的数值，不是环形变量 - DevTools 里看到 computed color 是
rgb()，说明插值早已落地完成，无法回溯
in lch / in oklch 也不自动避让灰区，需配合停靠点密度
in oklch 确实让 L/C/h 解耦，但浏览器仍只在两个相邻色标之间做插值。如果停靠点太稀疏（如 0% → 100%），这段插值还是落在 sRGB 底层，照样出灰。
- 视觉上最易出灰的区间集中在 40%–60%，所以停靠点间隔必须 ≤20%
- 哪怕用了
oklch(70% 0.3 30) 0%, oklch(70% 0.3 210) 100%，也得手动加中间点：oklch(70% 0.3 90) 50%或更密 - oklch 中的
h值不带单位，写成30deg会静默失效，只认纯数字
混用颜色格式会让整个渐变退化到 sRGB
只要渐变列表里有一个 rgb()、#fff 或 rgba()，浏览器就放弃所有色彩空间声明，整条渐变 fallback 到 srgb 插值——你写的 in oklch 形同虚设。
- 所有色标必须统一为
oklch(L C h)或全用lch(L C h)，L 必须带%，C 不能带单位，h 不加deg - 禁用
background简写——它会把oklch()转成rgb()后缓存，失去意义 -
rgba()和任何带 alpha 的写法都别碰，alpha 通道独立插值会放大灰阶偏差
真正难的不是写出第一个 in oklch 渐变，而是确保每个字符都符合规范：格式统一、位置精确、无简写污染、无 alpha 干扰——漏掉任意一环，浏览器就立刻切回 sRGB，灰带重现。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
