css无法实现真正的hdr颜色控制，因oklch()、color(display-p3)等函数均运行于sdr管线，亮度被硬性clamp至0–100 nits，无api触发系统hdr模式或输出pq/hlg信号；color-mix(in oklab, )仅优化混合一致性，webgpu是当前唯一可行hdr路径。
不能在 CSS 中精确控制颜色在 SDR 和 HDR 之间的映射 —— 浏览器根本不提供该能力，所有 oklch()、color(display-p3)、ictcp() 等函数都运行在 SDR 渲染管线内，亮度被硬性 clamp 到 0–100 nits，且无 API 可触发系统级 HDR 模式切换或 PQ/HLG 信号输出。
为什么 oklch(120% 0.4 300) 不会变亮
这不是数值写错了，而是浏览器根本不会把 L 值 >100% 当作 HDR 信号处理。所有 Color Level 4 函数（oklch、jzazbz、ictcp）仅用于更均匀的色域表达，不是 HDR 协议。它们的 L 通道仍映射到 D65 白点（≈80 nits），超出 100% 的部分被截断，DevTools 显示的值 ≠ 实际输出亮度。
-
oklch(90% 0.3 270)在 iPhone 或 MacBook Pro 上渲染结果和oklch(100% 0.3 270)几乎一样，因为底层仍是 SDR 合成 - 即使显示器支持 XDR、系统开启了 HDR，CSS 也完全感知不到 ——
@media (dynamic-range: high)在 Chrome/Firefox 返回false，Safari 仅做设备匹配，不改变渲染逻辑 -
color-mix(in oklab, ...)是唯一视觉上“接近 HDR 感”的操作，但它只优化混合一致性，不提升亮度上限
color(display-p3) 的生效条件极其苛刻
写了 color(display-p3 0.98 0.35 0.35) 不等于用了 P3 —— 它只是语法合法，是否走 P3 渲染路径取决于三重链路同时就绪：
- 设备硬件：iPhone 12+、MacBook Pro M1+、少数高端 Windows 笔记本；多数安卓机、普通显示器直接降级
- 系统层：iOS/macOS 默认开启，但企业 MDM 策略可能禁用；Windows 需手动启用“HDR”开关，且对网页无效
- 浏览器渲染栈：Safari 最稳定，Chrome 125+ 仅在
chrome://flags#enable-color-gamut-p3开启后部分支持；Firefox 仍无实质进展 - 页面上下文缺失也会导致失效：
<meta name="color-scheme" content="light dark">缺失、父元素用了transform或filter、未用@supports (color: color(display-p3 0 0 0))包裹
真正需要 HDR 输出时，必须绕开 CSS
如果你的应用场景涉及 BT.2100/PQ 标准（如视频预览、专业校色工具），CSS 完全不在考虑范围内：
-
<canvas></canvas>和 WebGL：不支持 HDR 纹理格式，OffscreenCanvas也不行 - WebGPU 是当前唯一可行路径：需创建
GPUTextureFormat.rgba16float纹理，并在GPUContext.configure()中指定presentationFormat: "hdr10" - 支持现状：仅 Chrome 125+ 实验性支持，需启用
chrome://flags#enable-webgpu-developer-features，且依赖 GPU 驱动、显示器 EDID 和操作系统 HDR 状态联动 - 注意：
video-dynamic-range属性只作用于<video></video>元素，与 CSS 颜色无关，也不能响应屏幕亮度变化
实际开发中最容易被忽略的一点：所谓“HDR 颜色适配”，99% 的情况其实是宽色域（P3/BT.2020）+ 感知均匀空间（OKLAB）的组合问题，而非动态范围本身。别在 oklch() 里调 L 值试图提亮，先验证 window.matchMedia("(color-gamut: p3)").matches 是否为 true，再决定 fallback 方案。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
