srgb色域物理上限低于display p3，rgb(255,0,100)等值在广色域设备上会被压缩截断；浏览器对未声明空间颜色默认按srgb解析但输出策略不同：safari映射p3、chrome守srgb、firefox最保守；color(srgb)可锁定渲染路径但需前置fallback，且旧版或特殊环境可能失效。
sRGB 色彩空间本身无法表达 Display P3 或 Rec.2020 中的高饱和红、绿区域，写 rgb(255, 0, 100) 看似“够红”，实际在广色域设备上会被压缩到 sRGB 三角形内——这不是渲染错误，是色域上限被物理截断。
Display P3 中的红色在 sRGB 里根本不存在
Display P3 的红色原点坐标是 (0.68, 0.32)（CIE xy），而 sRGB 的红色原点只有 (0.64, 0.33)。这意味着：
- 设计师在 Figma 里选的 “P3 红”（如 color(display-p3 1 0 0)）在 sRGB 屏幕上必然失真
- 即使你手动把 P3 值转成 rgb() 数字，浏览器仍按 sRGB 解码，结果不是“近似”，而是“最近可表示点”——通常偏橙、发粉或变暗
- #FF0000 在 MacBook Pro 上可能显示为偏紫的亮红，在 Dell S2721DGF 上则更接近砖红，差异来自色域映射策略，而非亮度或校准问题
浏览器对未声明色彩空间的值默认按 sRGB 解析，但不保证按 sRGB 输出
W3C 明确规定：rgb() 和 #RRGGBB 默认绑定 sRGB，但最终是否“按 sRGB 显示”，取决于：
- macOS Safari 15.4+ 会将未声明空间的颜色自动映射到 Display P3（即使你写了 rgb(255, 0, 0)）
- Chrome 桌面版多数情况下保持 sRGB 输出路径，但若 GPU 驱动上报了 P3 能力且页面启用了广色域上下文，也可能悄悄提升输出精度
- Firefox 目前基本守 sRGB 基线，但不主动做色域扩展，也不拦截 P3 降级，表现最“稳定”也最“保守”
- 所以同一行 background-color: #FF0000;，在不同环境里既不是 bug，也不是兼容问题，而是规范留白下的合理分歧
用 color(srgb) 显式声明反而可能暴露旧浏览器解析缺陷
看似更精确的写法，实操中容易踩坑：
- color(srgb 1 0 0) 在 Chrome 111+、Safari 16.4+、Firefox 117+ 中能锁定 sRGB 渲染路径，但旧版本直接忽略整条声明 → 若没前置 fallback，颜色就消失了
- 更隐蔽的问题是：部分 Chromium 分支（如某些 Electron 22 构建）会把 color(srgb) 当作普通函数处理，却未正确实现 sRGB 到帧缓冲区的 gamma 校正，导致颜色比预期偏暗
- 如果你同时用了 filter: brightness(1.1)，它会在 sRGB 空间做线性提亮，破坏人眼感知一致性，让本就不饱和的红色显得更“假”
真正要保鲜艳度，不是“换写法”，而是控制输入源头：设计师导出切图时必须勾选「转换为 sRGB」，前端禁用 color(display-p3) 除非全链路可控，否则 #FF0000 反而是当前 Web 生态下最可预期的红色起点。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
