OKLCH是目前唯一能支撑自动化主题配色的CSS原生颜色空间，其L值跨色相保持视觉一致，降级需外置fallback且检测值带单位，参数须严格按规范书写。
OKLCH 不是“更适合”，它是目前唯一能支撑自动化主题配色的 CSS 原生颜色空间——前提是调参逻辑对齐 WCAG 感知要求，而不是照搬 HSL 习惯。
oklch() 的 L 值真能跨色相保持视觉一致
HSL 的 lightness 是 RGB 极值的数学平均，hsl(0, 100%, 50%)（纯红）和 hsl(120, 100%, 50%)（纯绿）在 CIE Y 明度上实测差三倍；而 oklch(50% 0.32 0) 和 oklch(50% 0.32 120) 在人眼看来才真正“一样亮”。这对自动化生成 10 级色阶至关重要：你设定 L = 90% → L = 12% 的线性映射，每级在所有色相下都具备可预测的对比度潜力，不用为黄、紫、青单独写补偿逻辑。
@supports 降级结构一错，整个主题就失效
OKLCH 不支持时浏览器不会报错，而是静默跳过整条声明。如果 fallback 写错位置或单位不对，UI 可能直接变黑、透明或错色：
- 降级色必须写在
@supports块**外部且上方**：color: #1e293b;→ 再跟@supports (color: oklch(0% 0 0)) { color: oklch(22% 0.02 55); } - 检测值必须带单位：
@supports (color: oklch(0% 0 0))✅，@supports (color: oklch(0 0 0))❌（Safari/Chrome 都返回 false） - 绝对禁用
@supports not：安卓 WebView 解析会崩溃整块规则
渐变和禁用态必须分策略调参，不能套用 HSL 经验
OKLCH 的解耦优势只有在参数分工明确时才成立：
立即学习“前端免费学习笔记（深入）”；
- 禁用态：固定
H和L，只降C—— 例如oklch(62% 0.28 258.5)→oklch(62% 0.12 258.5)；若同时降L，浅底文字可读性会断崖下跌 - 深色模式：固定
H和C，只调L——oklch(96.8% 0.018 80)→oklch(14% 0.018 80)，避免 OLED 屏幕下L < 5%导致像素熄灭 - 渐变跨 0°/360°（如 350° → 10°）必须手动拆段：
linear-gradient(oklch(0.7 0.25 350), oklch(0.7 0.25 0), oklch(0.7 0.25 10))，否则中间段色度被强制压缩，出现灰紫色带
OKLCH 的 L 必须带单位，C 必须是小数，H 后不加 deg
一个字符写错，整条声明就静默失效：
-
oklch(60 0.28 258.5)❌（L 缺 %，Chrome/Safari 拒斥） -
oklch(60% 28% 258.5)❌（C 不能写百分比，必须是无单位小数如0.28） -
oklch(60% 0.28 258.5deg)❌（H 加deg在 Safari 16.x 和部分安卓 WebView 中解析失败） -
oklch(60% 0.28 258.5 / 0.8)✅（alpha 必须用/分隔）
最安全写法是 oklch(60% 0.28 258.5)，兼容性覆盖 Chrome 111+、Firefox 120+、Safari 17.4+；用小数形式 oklch(0.6 0.28 258.5) 则需注意 Safari 对小数位敏感（建议 H ≤ 1 位小数）。
