css中无法定义真正的hdr颜色，因oklch()等函数仅在sdr范围内解析，亮度被硬性clamp至0–100 nits；真正hdr需pq/hlg标记、系统hdr模式及硬件全链路支持，web平台尚未打通，当前唯一实用方案是color-mix(in oklab, )。
CSS 中无法通过高比特位定义真正的 HDR 颜色 —— 所有 oklch()、ictcp()、jzazbz() 等 Color Level 4 函数目前都运行在 SDR 限制下，亮度值被硬性 clamp 到 0–100 nits 范围内，与设备是否支持 HDR 无关。
为什么 oklch(90% 0.3 270) 不等于 HDR 效果
这些函数是「宽色域 + 感知均匀」的色彩空间，不是 HDR 输出协议。它们能更准确表达 P3 或 Rec.2020 色域内的颜色（比如深紫、亮青），但亮度通道（L）仍映射到标准白点（D65, ~80 nits），浏览器不会将其解释为 >100 nits 的信号。即使你写 oklch(120% ...)，实际渲染时 L 值会被截断为 100%。
- DevTools 里看到的数值 ≠ 实际输出亮度
- 显示器不会因此切换到 HDR 模式，系统级 HDR 开关（如 macOS 的“高动态范围”）对 CSS 渲染无影响
-
color(display-p3 0.8 0.2 0.9)只扩展色域，不提升动态范围
dynamic-range: high 媒体查询为何基本无效
截至 2026 年 5 月，@media (dynamic-range: high) 在 Safari 中可能匹配 XDR 显示器设备，但：
- 它不触发任何渲染行为变化：
rgb()、hsl()、oklch()解析逻辑完全不变 - Chrome 和 Firefox 尚未实现该媒体查询，返回始终为
false -
dynamic-range-limit: high属性无浏览器支持，CSS 规范中仍为草案状态
当前唯一可用的“HDR 相关”实操方案：用 color-mix(in oklab, ...)
虽然不能输出 HDR，但 oklab 空间对明度（L）和色度（a/b）解耦更符合人眼感知，做颜色混合时视觉稳定性远超 srgb，特别适合深浅主题自动适配：
- 必须显式写
in oklab，省略则退化为 gamma 非线性混合 - 示例：
color-mix(in oklab, var(--primary) 60%, white 40%)在深色背景下不会发灰，在浅色下不易过曝 - 对比
rgba(var(--primary), 0.6)：后者在暗背景上常出现“雾感”，因 sRGB 混合不尊重亮度感知一致性
真 HDR 渲染只能绕开 CSS，走 WebGPU 底层路径
如果你的应用确实需要 BT.2100/PQ 信号输出（如专业视频预览、HDR 校色工具）：
- Canvas 2D / WebGL 不支持 HDR 纹理格式；
OffscreenCanvas也不行 - WebGPU 是目前唯一可行路径：需创建
GPUTextureFormat.rgba16float纹理，并在GPUContext.configure()中指定presentationFormat: "hdr10" - 仅 Chrome 125+ 在启用
chrome://flags#enable-webgpu-developer-features后提供实验性支持，且依赖 GPU 驱动和显示器全程 HDR 链路
别指望靠改几个 CSS 值就让网页变 HDR —— 缺失的是整个输出栈：从 CSS 解析器、合成器、GPU 驱动到显示接口，目前没有一环打通。真正落地前，color-mix(in oklab, ...) 是最务实的颜色可控手段。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
