oklch()需严格按l%c°h°/α格式书写，l∈[0%,100%]、c须带%或为小数、h后加deg、α用/分隔；跨0°插值需防绕圈、color-mix须同色空间、@supports降级色须前置；devtools不显示原值，仅靠视觉验证。
oklch() 现在就能用，但**只在 Chrome 112+、Firefox 121+、Safari 17.4+ 中生效**；旧版本或多数安卓 WebView 会静默忽略整条声明，直接回退到前一条颜色（比如 color: oklch(60% 0.2 240); color: #3b82f6;，老浏览器只认 #3b82f6）。
如何写对 oklch() 参数才不被浏览器丢弃
错一个单位，整条规则就失效，不是变灰，是彻底消失。
-
oklch(60 0.2 240)❌ —— L 缺%，Chrome 112 会拒斥 -
oklch(60% 0.2 240)❌ —— C 缺单位（必须是20%或0.2，但不能混用；0.2合法，20%也合法，但不能写成0.2+240deg却漏掉 C 的单位标识） -
oklch(60% 0.2 240deg)✅ —— 全部显式带单位，且顺序固定：L → C → H -
oklch(60% 0.2 240 / 0.8)✅ —— alpha 必须用/分隔，不能写成oklch(60% 0.2 240, 0.8) - L 范围是
0%–100%（或0–1），不是0–255；C 实际安全上限取决于色相——蓝绿区可达0.35，红橙区常卡在0.22左右，超限会被 clamp 成灰阶
为什么用 oklch() 调明度比 hsl() 更可靠
因为人眼对亮度的感知是非线性的：hsl(240, 100%, 50%) 到 hsl(240, 100%, 60%) 看起来几乎没变亮，而 hsl(240, 100%, 90%) 却突然刺眼。这不是你的显示器问题，是 HSL 模型本身缺陷。
-
oklch(0.5 0.25 240)→oklch(0.6 0.25 240)：ΔL = 0.1，视觉明度提升均匀可预期 - 深色模式中做
background渐变时，用oklch(0.15 0.05 240)→oklch(0.25 0.05 240)比用hsl()更少出现“中间一段发灰”或“跳变” - 但注意：CSS 自定义属性无法保留色彩空间信息，
--primary: oklch(0.6 0.25 240); transition: background 0.3s;动画实际走的是 sRGB 插值，OKLab 均匀性完全丢失
用 oklch() 写渐变和主题色时最容易踩的三个坑
视觉上看着对，上线后用户看到的可能是另一回事。
- 跨
0°/360°做色相插值（如oklch(0.7 0.2 350)→oklch(0.7 0.2 10)）：OKLCH 不自动走短弧，会从 350° 绕一圈到 10°，渐变中出现意外灰带；应手动拆成两段，或改用calc()控制色相差 ≤ 180° -
color-mix()里混用色彩空间：color-mix(in oklch, oklch(0.6 0.25 240), red)整条声明被忽略（连 fallback 都不触发），必须两端都用oklch()值 - @supports 检测写错位置：降级色必须写在
@supports块**外部且上方**，否则部分 WebView 会跳过后续所有规则；正确写法是先写color: #3b82f6;，再写@supports (color: oklch(0% 0 0)) { color: oklch(60% 0.25 240); }
调试 oklch() 时 DevTools 给不了你真实值
Chrome 和 Safari 的开发者工具里，Computed 面板永远只显示转换后的 sRGB 十六进制（比如 #3b82f6），复制出来的值也是降级结果。你改了 oklch() 参数，面板毫无反应——不是没生效，是它根本不展示 OKLCH。
-
getComputedStyle(el).backgroundColor返回的仍是 sRGB 字符串，不是原始oklch() - 真正验证行为，只能靠视觉比对：准备一组已知 OKLCH 值的色块，在支持的浏览器里打开，和设计稿逐像素对照
- 日常建议把 C（色度）控制在
0.28以内：兼顾表现力、色域安全性和跨设备一致性；超过这个值，iOS 17.3 及更早系统、部分 OLED 屏幕可能渲染异常
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
