oklch超出srgb时浏览器静默clamping，将超限值映射到色域边界最近点而不提示；青蓝区（h≈210–270）最易失真，l越低c上限越小，各浏览器clamping结果不一致，需实测验证。
OKLCH超出sRGB时浏览器静默clamping，不是报错也不是警告
浏览器不会提示“颜色越界”，也不会在DevTools里标红；它直接把超限的OKLCH值映射到sRGB色域边界上最接近的点——这个过程叫clamping，且完全静默。你写的oklch(60% 0.35 240)在iPhone上渲染出来可能就是一块灰蓝，但Chrome DevTools颜色拾取器仍显示原始值，造成“明明写了却没生效”的错觉。
青蓝区（H≈210–270）最容易触发clamping
这个区间对色度C极其敏感，尤其在中低明度下：
-
oklch(60% 0.28 240)通常能安全显示 -
oklch(60% 0.32 240)在多数安卓旗舰机上已开始发灰 -
oklch(40% 0.25 240)比同C值的oklch(70% 0.25 240)更易失真——L越低，sRGB可表达的C上限越小
不同浏览器clamping策略不一致，无法预测中间色
Chrome、Safari、Firefox都做clamping，但算法细节未标准化：
- 同一
oklch(50% 0.3 250)在Chrome里可能被压成rgb(90, 120, 180)，在Safari里变成rgb(85, 115, 175) - 没有浏览器会插值后裁剪，而是先转sRGB再线性混合——所以
linear-gradient(oklch(50% 0.3 250), oklch(70% 0.3 250))中间色依然可能发灰 - 想验证是否越界？用
colorjs.io输入OKLCH值，看它是否标注“out of sRGB”
避免clamping的实操底线
不是靠“试出来”，而是守住几条硬约束：
- 青蓝区（H 210–270）务必把
C压到≤0.25，L≥60%时可放宽到0.28 - 禁用
C > 0.3的OKLCH值用于文本或小面积UI——对比度和可读性会断崖下跌 - 深色模式下慎用高C值：sRGB在暗背景下本就压缩色域，
oklch(30% 0.22 240)可能比oklch(30% 0.18 240)更不可靠 - 别依赖
color-mix(in oklch, ...)规避问题——它不改变clamping行为，只换了个插值路径
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
