oklch() 并非 HEX 升级，而是专为设计系统提供感知一致、可推演的颜色控制：L 控明暗不偏色，C 控饱和不改明暗，H 控色调不掉彩；HEX 无法满足语义化调色与无障碍对比需求。
oklch() 不是 HEX 的“升级替代”，而是解决不同问题的工具。HEX 仍适合静态占位、图标内联或构建时硬编码；但设计系统需要语义化、可推演、跨状态一致的颜色行为——这时必须用 oklch()，否则调色、适配、无障碍对比度控制全靠人眼硬猜和反复试错。
HEX 在设计系统里根本没法调色
HEX 是设备输出值，不是人眼感知描述。比如 #4a90e2，你无法从数字判断它偏蓝还是偏青，更没法回答：“把它变浅 10% 明度，同时保持不发灰、不偏紫”——因为 RGB 通道线性叠加和人眼亮度响应完全不对齐。
而 oklch(60% 0.28 258.5) 中：
• 60% 是感知亮度，调它就真变亮/变暗，不偏色
• 0.28 是色度，降它就真变灰，不改明暗
• 258.5 是色相，动它就真转色调，不掉饱和
所有操作都可预测、可复现、可写进设计 Token 规则里。
@supports 降级结构一写错，整个按钮就变黑
oklch() 不支持时不是报错，是整条声明被静默跳过。如果你只写：
button { background-color: oklch(60% 0.28 258.5); }旧浏览器直接没颜色，按钮透明或继承父背景，UI 崩溃。
正确做法只有这一种结构：
• 降级色必须写在
@supports 块**外部且上方**• 检测值必须带单位：
@supports (color: oklch(0% 0 0))✅，@supports (color: oklch(0 0 0))❌• 绝对不用
@supports not，安卓 WebView 会解析失败• 别用
oklab() 检测，所有主流浏览器目前都返回 false
渐变和禁用态逻辑在 HEX/HSL 下天然断裂
CSS 渐变插值发生在色彩空间内部。HEX/HSL 写 linear-gradient(#4a90e2, #e74c3c)，浏览器先转成 sRGB，再线性插值，中间必然经过灰褐断层；HSL 同样如此，hsl(210, 70%, 60%) → hsl(0, 70%, 60%) 实际经过暗紫、灰棕。
而 oklch() 要求：
• 色相差 >180°（如 350°→10°）必须手动拆段：linear-gradient(oklch(0.7 0.25 350), oklch(0.7 0.25 0), oklch(0.7 0.25 10))
• 禁用态只能降 C（如 0.28 → 0.12），不能动 L，否则文字在浅底上可读性断崖下跌
• 深色模式只调 L（如 62% → 38%），固定 C 和 H，蓝调才稳定不发紫
这些规则在 HEX/HSL 里根本不存在对应语义，硬套只会让设计系统越维护越碎。
L 值缺 % 就失效，C 值写成百分比也失效
oklch() 对格式极其敏感：
• oklch(60 0.28 258.5) ❌ —— L 缺 %，Chrome/Firefox/Safari 全部静默忽略
• oklch(60% 28% 258.5) ❌ —— C 必须是无单位小数（0.28），写成 28% 无效
• oklch(60% 0.28 258.5deg) ❌ —— H 后加 deg 在 Safari 16.x 和部分安卓 WebView 中解析失败
• oklch(60% 0.28 258.5 / 0.8) ✅ —— alpha 必须用 / 分隔，不能用逗号
DevTools 的 computed 样式永远只显示降级后的 sRGB 十六进制值，看不到真实 OKLCH 行为。真值只能靠肉眼比对 + 限制 C ≤ 0.28 控制色域漂移风险。
立即学习“前端免费学习笔记（深入）”；
真正难的不是把 HEX 替换成oklch() 字符串，而是把“调色”这件事从经验主义切换到模型驱动——L、C、H 各司其职，但每个参数的取值边界、单位约束、跨浏览器降级链、渐变插值路径，都得重新建立直觉。漏掉其中任何一环，设计系统就退回“改一个颜色，测三台设备，修五个 bug”的状态。 
