OKLCH不能存于CSS变量中直接调用，因自定义属性仅文本替换；必须用@supports写死检测并降级，参数仅H/C可变量化且需单位合规，深色/禁用态须独立声明完整OKLCH值。
OKLCH变量不能直接存函数调用
你不能写 --primary: oklch(62% 0.28 258.5); 然后在其他地方用 color: var(--primary); —— 这个变量值会被浏览器当作普通字符串解析，oklch() 不会在计算时重新解析，最终渲染为无效颜色（常表现为透明或继承色）。CSS 自定义属性不保留色彩空间语义，它只做文本替换。
@supports检测必须绕过变量间接引用
想用 OKLCH 又要降级，唯一可靠路径是把 @supports 块写死在选择器内部，而不是靠变量控制。常见错误是试图用 JS 或 CSS 变量动态切换检测逻辑，结果安卓 WebView 或旧 Safari 直接跳过整块规则。正确结构只能是：
button {
background-color: #2563eb;
}
@supports (color: oklch(0% 0 0)) {
button {
background-color: oklch(62% 0.28 258.5);
}
}- 降级色必须写在
@supports块外部且上方 - 检测值
oklch(0% 0 0)缺单位（如写成oklch(0 0 0)）会导致所有浏览器返回false - 绝对不用
@supports not，安卓 WebView 解析会崩溃整条规则
真正能变量化的只有参数片段
如果你非要复用 OKLCH 的某部分，只能拆开存：比如固定色相和色度，只让亮度可变，可以这样写：
:root {
--primary-h: 258.5;
--primary-c: 0.28;
}
button {
background-color: #2563eb;
}
@supports (color: oklch(0% 0 0)) {
button {
background-color: oklch(62% var(--primary-c) var(--primary-h));
}
}- H 和 C 可以作为变量注入，但 L 必须带单位且不能是变量（
var(--primary-l)无法保证单位存在） - 这种写法仅在 Chrome 112+/Firefox 121+/Safari 17.4+ 生效；旧版本会忽略整条
oklch()声明 - 所有节点必须统一用
oklch()，混用hsl()或rgb()会让渐变、transition 回退到 sRGB 插值，失去感知均匀性
深色模式与禁用态必须独立声明，不能靠变量推导
OKLCH 的价值在于 L/C/H 分离控制，但“同一主色 → 深色模式”不是简单改一个变量就能搞定的。实测表明：
立即学习“前端免费学习笔记（深入）”；
- 深色模式应固定 H 和 C，只调 L：
oklch(62% 0.28 258.5)→oklch(38% 0.28 258.5) - 禁用态应固定 H 和 L，只降 C：
oklch(62% 0.28 258.5)→oklch(62% 0.12 258.5)，否则浅背景上文字对比度会断崖下跌 - 别用
calc()对 L 做算术运算，oklch(calc(62% - 20%) 0.28 258.5)在低 L 区域非线性极强，实测对比度可能从 7.2:1 骤降至 2.1:1
这些策略无法压缩进单个变量，必须为每种状态写出完整、带单位、经实测验证的 OKLCH 值。
