OKLCH颜色超出显示器色域后失真，是因为浏览器根本未尝试色域映射，所有oklch()值均在SDR管线中被硬性截断：L>100%直接clamp至100%，超出色域的C值被无声丢弃，DevTools显示值≠实际送显值；postcss-oklab转换仅做D65逆变换+clamping保底，非色域适配。
OKLCH颜色超出显示器色域后失真，不是因为浏览器“尽力而为”，而是它根本没尝试映射——所有oklch()值都在SDR管线里被硬性截断，连色域判断这一步都跳过了。
浏览器根本不做色域适配
你写的oklch(0.9 0.45 180)（高饱和青绿）可能远超sRGB，但Chrome、Safari、Firefox都不会把它送去P3或Rec.2020通道处理。它们统一走D65白点+Gamma 2.2的SDR合成路径，L值>100%直接clamp到100%，C值超出当前输出色域的部分被无声丢弃。DevTools里显示的数值≠实际送显值，更不等于人眼看到的亮度/饱和度。
PostCSS转换会clamped，但不是“适配”而是“保底”
postcss-oklab插件把oklch()转成rgb()时，并不模拟显示器色域边界，而是用固定D65白点做逆变换，再对结果执行Math.round()和clamping：任何R/G/B >255 → 255，
- 高C蓝紫区域（如
oklch(0.5 0.35 270)）→rgb(102, 128, 255)，视觉发灰 - 鲜绿色（
oklch(0.9 0.4 120)）→rgb(180, 255, 160)，饱和度掉约15% - 转换结果永远是整数
rgb()，不会出现小数位
@supports检测不到真实色域能力
@supports (color: oklch(0% 0 0))只测语法支持，不测输出能力。即使检测通过，color(display-p3)也未必生效——Windows需手动开HDR开关，macOS需系统级P3启用，且Chrome直到v117才默认启用P3输出通道。更关键的是：@media (dynamic-range: high)在Chrome/Firefox始终返回false，Safari仅匹配设备型号，不触发HDR渲染逻辑。
立即学习“前端免费学习笔记（深入）”；
真正能绕过色域限制的路径只有一条
WebGPU是当前唯一可控制PQ/HLG信号输出、访问系统HDR模式的API。CSS里的oklch()、color(display-p3)、color-mix(in oklab, )全运行在SDR合成器内，亮度被锁死在0–100 nits。所谓“HDR感”只是视觉混合优化，不是物理亮度提升——这点在MacBook Pro XDR屏上实测与普通LCD无异。
