OKLCH可解决多显示器颜色不一致，但需严格遵循规范：L用%或0–1、C为无单位小数、H不带单位、alpha用/分隔；@supports检测必须显式且顺序正确；白点需统一为D65并借助专业工具转换。
OKLCH 能解决多显示器下颜色感知不一致的问题，但前提是写法完全正确、降级逻辑到位，否则老设备上直接变黑或灰块。
oklch() 参数单位错一个，整条声明就静默失效
浏览器不会报错，也不会 fallback 到下一条——它直接跳过整行。常见写错形式包括：oklch(60 0.28 258.5)（L 缺%）、oklch(60% 28% 258.5)（C 用了百分比，但 OKLCH 要求 C 是无单位小数）、oklch(60% 0.28 258.5deg)（Safari 16.x 和部分安卓 WebView 会解析失败）。
必须严格按规范写：oklch(60% 0.28 258.5) 或 oklch(0.6 0.28 258.5)（后者仅 Chrome 112+/Firefox 121+/Safari 17.4+ 支持，且 H 值建议四舍五入到一位小数）。
- L 必须是
0%–100%或0–1，不能混用； - C 必须是纯小数（如
0.28），不能写28%； - H 推荐不带单位（
258.5），带deg在旧 Safari 中风险高； - alpha 必须用
/分隔：oklch(60% 0.28 258.5 / 0.8)，不能用逗号。
@supports 检测必须写在回退色之后，且不能反序
只靠两条颜色声明（background-color: #2563eb; + background-color: oklch(60% 0.28 258.5);）不够稳妥。某些安卓 WebView 会跳过所有后续声明，导致 OKLCH 完全不生效。
立即学习“前端免费学习笔记（深入）”；
唯一可靠方式是显式用 @supports (color: oklch(0% 0 0)) 包裹，并确保降级色写在块外部且上方：
button {
background-color: #2563eb;
}
@supports (color: oklch(0% 0 0)) {
button {
background-color: oklch(60% 0.28 258.5);
}
}
- 别用
@supports (color: oklab(0 0 0))—— 所有主流浏览器目前都返回false； - 别用
@supports not—— 部分 WebView 解析异常； - 检测值必须带单位：
oklch(0% 0 0)，不能写oklch(0 0 0)； - fallback 颜色必须在
@supports块外定义，顺序不能颠倒。
跨显示器一致性依赖白点声明和色域控制
OKLCH 默认使用 D50 白点，但多数设计工具和转换器默认输出 D65。若你从 HEX 直接粘贴到在线转换器再抄进 CSS，没声明白点，颜色就会漂移——同一段 oklch() 在 MacBook Pro 和 Dell S2721DGF 上看起来明显不同。
正确做法是先通过支持白点标注的库（如 colorjs.io）将原始色转为明确色空间的中间表示，再导出 OKLCH：
- 输入
#2563eb→ 解析为color(srgb 0.145 0.388 0.922)； - 再转为
oklch(0.62 0.28 258.5)（保留一位小数）； - C 值别超安全上限：蓝区 ≤ 0.28，红橙区 ≤ 0.22，避免被 clamp 成灰阶；
- 深色模式中只调 L（如
0.62 → 0.38），禁用态只降 C（如0.28 → 0.12），H 绝对不动。
最易被忽略的是：DevTools 里永远看不到真实 OKLCH 值，computed 样式只显示降级后的 sRGB；调试只能靠真机比对 + JS 读取 getComputedStyle(el).backgroundColor 再人工验证。一旦漏掉单位、写错顺序、或跨 0°/360° 插值，问题就藏得极深。
