OKLCH 的 C（Chroma）是感知色度绝对量，非饱和度滑块；必须用 0–1 无单位小数，写错单位、超限或混用白点会导致发灰、banding 或静默失效。
OKLCH 的 C（Chroma）不是“饱和度滑块”，它代表人眼感知的色度绝对量——调高它不等于更“艳”，而是更逼近设备色域边界；写错单位、超限或混用白点，立刻导致颜色发灰、banding 或静默失效。
Chroma 参数必须是无单位小数，不能写百分比
这是上线后颜色突然变灰的头号原因。浏览器对 oklch() 的解析极其严格：C 必须是 0–1 范围内的纯小数（如 0.28），写成 28% 或 28 都会整行静默忽略，不报错也不 fallback。
-
oklch(60% 0.28 258.5)✅ 安全通用写法 -
oklch(60% 28% 258.5)❌ Safari / Chrome 全部拒斥 -
oklch(60% 28 258.5)❌ L 缺 % 且 C 超出范围，双重失效
实测中，C > 0.32 在多数 sRGB 屏幕上已接近青/蓝区上限，继续拉高只会触发浏览器 clamp 或渲染抖动。
Chroma 实际上限取决于 L 和 H，不是固定值
同一 C = 0.35 在红区（H: 0）可能饱满，在青区（H: 180）却溢出为灰带。这是因为 Chroma 受 OKLab 空间下亮度与色相的联合约束。
立即学习“前端免费学习笔记（深入）”；
- 典型安全区间（sRGB 屏幕）：
oklch(55% 0.25 120)（绿）、oklch(65% 0.22 0)（红）、oklch(60% 0.28 240)（蓝） - 超过这些值后，DevTools 中拖动 C 滑块会出现跳变、边缘锯齿或预览色块突然变暗
- 真机测试比模拟器更关键：MacBook Pro（P3）能撑到
C: 0.38，但普通笔记本 LCD 往往在0.28就开始 banding
别直接套用设计稿数值，D50/D65 白点差异会导致色相偏移
Figma/Sketch 默认导出 D50 白点下的 LCH，而 CSS 渲染强制走 D65 —— 这会让青绿色相偏移 3°–5°，尤其当你设 oklch(60% 0.3 180)（正青），实际渲染可能接近 183°，和设计稿对不上。
- 绝对不要用“LCH to HEX”在线转换器，它们默认按 D65 + sRGB 硬算，忽略白点转换逻辑
- 正确做法：用 colorjs.io 或支持白点标注的插件，把原始 HEX（如
#2563eb）先转为color(srgb ...)，再明确指定 D65 输出 OKLCH - 禁用态/深色模式下调参时，固定
H和C，只降L或微调C（如0.28 → 0.12），避免因白点漂移放大误差
渐变中高 Chroma 易暴露插值缺陷，必须手动拆段
CSS 对 oklch() 渐变不做色相短弧优化。写 oklch(0.7 0.3 350) → oklch(0.7 0.3 10)，浏览器会按数值线性插值：350 → 360 → 10，中间经过 H=0° 附近时，C 被强制压缩，出现灰紫色断层。
- 色相差 >180° 时，必须拆成至少三段：
linear-gradient(oklch(0.7 0.3 350), oklch(0.7 0.3 0), oklch(0.7 0.3 10)) - 所有节点必须统一用
oklch()，混入hsl()或rgb()会让插值退回到 sRGB 空间，彻底失去感知均匀性 - 动画中同样适用：CSS 关键帧里跨 0°/360° 的
oklch()变化，也得手动补中间节点
真正精准控制 Chroma，靠的不是拉满数字，而是理解它和 L、H、设备色域、白点之间的耦合关系——写错一个单位，或忽略一次白点转换，前面所有调色努力都会在某个 WebView 里无声崩塌。
