CSS无法实现真正的HDR效果，因sRGB色域和0–100 nits亮度范围天然不支持HDR，oklch()等函数仅在SDR管线中解析且亮度被硬性clamp，真正HDR需PQ/HLG信号、系统HDR模式及硬件全链路支持，当前Web平台尚未打通；唯一实用方案是color-mix(in oklab, )优化视觉一致性，或通过WebGPU底层API（如rgba16float纹理+hdr10输出）实现。
sRGB色域和亮度范围天然不支持HDR内容
sRGB色彩空间的设计目标是兼容CRT显示器和普通消费级屏幕，它把亮度限制在0–100 cd/m²，白点固定为D65，伽马曲线约2.2。而HDR内容（如BT.2100、Rec.2020）要求峰值亮度可达1000–10000 cd/m²，并使用PQ（Perceptual Quantizer）或HLG传输函数来编码更精细的亮度梯度。直接把HDR图像塞进sRGB通道，等于把10档光比压缩进3档——高光炸裂、暗部糊成一片。
CSS默认按sRGB解析所有rgb()和#RRGGBB值
即使你用color(display-p3 1 0.3 0.2)写了广色域值，浏览器对rgb(255, 99, 71)这类写法仍强制按sRGB解码。W3C规范明确：未声明色彩空间的RGB值，必须视为sRGB。这意味着：
- 设计师导出的P3色值，若没加
color(display-p3 ...)前缀，前端拿到的就是“被sRGB解释过的错色” -
background: #FF6347在P3屏上可能显示偏粉，在sRGB屏上偏橙，不是渲染bug，而是色彩空间误读 - Chrome DevTools 的 “Rendering” 面板里开启
Emulate color gamut才能复现这种偏差
现代CSS虽支持新色彩空间，但sRGB仍是默认兜底
CSS Color Level 4 引入了color(srgb ...)、color(display-p3 ...)、lch()、oklch()等语法，但它们不是替代sRGB，而是补充。关键现实是：
-
color(srgb 0.8 0.2 0.3)和rgb(204, 51, 76)在语义上等价，但后者无显式空间声明，浏览器仍可能按历史逻辑做隐式sRGB绑定 - 旧代码中大量存在的
rgba()、hsl()、渐变linear-gradient()，底层仍走sRGB插值路径，无法表达OKLCH中的感知均匀性 - 像
color-mix(in srgb, red, blue)这种写法，明确锁死在sRGB空间混合，结果必然受限于其窄色域
真正要显示HDR效果，得绕过CSS颜色系统本身
CSS目前没有原生HDR输出能力。所谓“HDR网页”，实际是靠<video>或<canvas>配合WebGL/WebGPU实现色调映射（tone mapping），再由操作系统+显卡驱动将信号送至HDR显示器。纯CSS样式层最多做到：
立即学习“前端免费学习笔记（深入）”；
- 用
@media (dynamic-range: high)检测HDR就绪状态（仅Safari 17.4+、Chrome 125+部分支持） - 切换
color(display-p3 ...)提升色域，但亮度仍卡在SDR范围 - 避免用
filter: brightness()模拟HDR——它只是线性提亮，破坏PQ编码的非线性感知分布
最易被忽略的一点：即使你写了color(display-p3 ...)，如果用户显示器没启用HDR模式（比如Windows里没开“使用HDR”开关），或者浏览器没通过matchMedia('(dynamic-range: high)')触发适配，那些值就还是按SDR路径走——色彩空间声明不等于自动HDR输出。
