CSS无法实现真正HDR显示，所有颜色函数均在SDR管线中执行且亮度被硬性截断至0–100 nits；@media (dynamic-range: high)仅检测硬件支持而不改变渲染逻辑；color(display-p3)扩展色域而非动态范围；唯一实用方案是color-mix(in oklab, ...)；真HDR需WebGPU配合GPUTextureFormat.rgba16float与系统级HDR支持。
CSS 无法定义真正支持 HDR 显示的高动态范围颜色。所有 CSS 颜色函数（oklch()、color(display-p3)、lch()）都在 SDR 渲染管线中执行，亮度值被硬性 clamp 在 0–100 nits 范围内，超出部分静默截断，不触发任何 HDR 输出行为。
为什么 @media (dynamic-range: high) 不起作用
这个媒体查询只声明“设备硬件支持 HDR”，不改变渲染逻辑，也不提升亮度上限：
- Safari 17.4+ 可能返回
true，但 Chrome 125+ 和 Firefox 115+ 当前仍返回false（window.matchMedia('(dynamic-range: high)').matches恒为false） - 即使匹配成功，
oklch(120% 0.4 270)中的120%会被截断为100%，无警告、无日志 - 它与系统是否开启 HDR 模式、显示器是否处于 HDR 状态完全无关——macOS 用户未打开“高动态范围”系统开关时也可能匹配
color(display-p3) 不等于 HDR，只是广色域
color(display-p3) 扩展的是色域（gamut），不是动态范围（dynamic range）：
- 它能让红色更饱和、绿色更鲜亮，但白点仍锁定在 ≈80–100 nits，无法表达 1000+ nits 的 HDR 亮度
- 生效需三重条件同时满足：设备硬件支持（如 MacBook Pro M1+）、系统启用 P3 渲染（Windows 需手动开 HDR 开关且对网页无效）、浏览器渲染栈支持（Chrome 需开启
chrome://flags#enable-color-gamut-p3） - 父元素若含
transform或filter，color(display-p3)可能直接降级回 sRGB
当前唯一实用的视觉一致性方案是 color-mix(in oklab, ...)
它不输出 HDR，但能避免深色/浅色主题下颜色发灰或过曝，因为 oklab 对明度（L）和色度（a/b）解耦更符合人眼感知：
- 必须显式写
in oklab，省略则退化为 sRGB 非线性混合，暗背景下文字易“发虚” - 示例：
color-mix(in oklab, var(--primary) 60%, white 40%)在深色模式下保持可读，在浅色模式下不刺眼 - 对比
rgba(var(--primary), 0.6)：后者在暗背景上常出现雾感，因 sRGB 混合未校正亮度感知 - 兼容性好（Chrome 111+、Safari 16.4+、Firefox 115+），不依赖媒体查询，也不需要用户开启 HDR
真 HDR 输出必须脱离 CSS。WebGPU 是目前唯一明确支持 HDR 渲染管线的标准：需用 GPUTextureFormat.rgba16float 存储高精度亮度值，并在 GPUContext.configure() 中指定 presentationFormat: "hdr10"。这仅在 Chrome 125+ 启用实验性 flag 后可用，且全程依赖 GPU 驱动、操作系统 HDR 开关和显示器物理支持——纯 CSS 层面没有任何接口可触达这一链路。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
