oklch(0% 0 0)是唯一被Chrome 112+、Firefox 121+、Safari 17.4+同时识别并返回true的合法最小输入，因浏览器对色彩函数支持逐函数落地，且语法容错极低，空格、单位、顺序任一偏差均导致检测失败。
只能用 @supports (color: oklch(0% 0 0)) 判断，其他写法基本无效——漏一个%、多一个空格、加deg，检测就失败。
为什么必须是 oklch(0% 0 0) 这个写法？
这不是随便凑的占位符，而是唯一被 Chrome 112+、Firefox 121+、Safari 17.4+ 同时识别并返回 true 的合法最小输入。浏览器对色彩函数的支持是逐函数落地的：oklab() 函数本身未启用，color-mix() 依赖额外上下文，都不能当判断依据。
-
@supports (color: oklch(0 0 0))❌ 缺%，Safari 16.x 和部分安卓 WebView 返回false -
@supports (color: oklab(0% 0 0))❌ 所有主流浏览器目前都返回false -
@supports not (color: oklch(0% 0 0))❌ 部分安卓 WebView 解析异常，整块被跳过 -
@supports (color: oklch(0% 0.0 0.0))❌ C/H 用了小数但没单位，Chrome 112–115 某些版本拒识
检测语句必须写在 fallback 颜色之后
CSS 是从上到下解析的。如果把 @supports 块写在前面，旧版 Chromium（如 Chrome 111 及更早）可能忽略后续所有声明，导致页面彻底无颜色可显示。
- ✅ 正确顺序：先写普通颜色声明，再写
@supports块 - ❌ 错误顺序：把
@supports块放在最前，fallback 写在后面 - fallback 必须是完整声明，不能只靠一条
color或background-color—— 某些环境会跳过整个后续规则链
检测值里空格、单位、顺序一个都不能动
哪怕多一个空格、少一个空格，某些安卓 WebView 就判定为无效语法，整条 @supports 块失效。它不像 JS 那样宽容，也不报 warning，静默跳过就是最终结果。
立即学习“前端免费学习笔记（深入）”；
-
oklch(0% 0 0)✅ 安全，所有支持 OKLCH 的浏览器都能识别 -
oklch(0% 0 0deg)❌ Safari 16.4–17.3 中触发解析失败 -
oklch(0 % 0 0)❌ 多空格，部分 WebView 拒绝解析 -
oklch(0% 0 0 / 1)✅ alpha 用/分隔也合法，但检测没必要加
真正容易被忽略的是：这个检测不是“有没有 OKLCH”，而是“能不能安全解析 OKLCH 声明”——它不保证 color-mix() 或 in oklch 可用，也不代表设备能显示广色域。只要浏览器引擎认得 oklch(0% 0 0) 这串字符，就进块；否则就走降级。细节错一点，整块就消失。
