同一CSS颜色值在不同屏幕显示效果不同，因其RGB数值需映射到各设备独有的色彩空间（如sRGB、DCI-P3），而设备色域、白点、gamma等参数各异，且浏览器色彩管理支持不一。
不同屏幕显示同一 CSS 颜色值，本质是 RGB 值被映射到各自设备的色彩空间
你写的 #FF6B35 在代码里是固定的 24 位 RGB 整数，但最终人眼看到的颜色，取决于这块屏幕如何解释这组数字。每块屏幕有自己的 RGB 色彩空间（比如 sRGB、DCI-P3、Adobe RGB），它定义了：红、绿、蓝三原色各自的真实色坐标（CIE xy）、白点（D65 还是 D50）、以及亮度响应曲线（gamma）。没有统一的物理基准，rgb(255, 107, 53) 就只是个“代号”，不是颜色本身。
sRGB 是 Web 的默认假设，但并非所有屏幕都按 sRGB 渲染
浏览器在无额外提示时，把所有未标记色彩空间的 CSS 颜色（如 rgb()、hex、hsl()）当作 sRGB 解释，并尝试在输出端做 sRGB → 设备色彩空间的转换。问题在于：
- 老旧或低端显示器可能根本没有准确的 sRGB 模式，出厂校准偏差大，甚至 gamma 错设为 2.2 以外的值
- MacBook Pro 或 iPhone 等支持
display-p3的设备，在 Safari 中会将color(display-p3 ...)显式渲染为更广色域，但对普通#FF6B35仍走 sRGB 路径 —— 只是它的 sRGB 到 P3 转换表可能和 Windows 机器不同 - Windows 上部分浏览器（如 Chrome）启用
color-management后会读取系统 ICC 配置文件；而 Firefox 默认禁用，直接硬映射到 sRGB
CSS 中显式指定色彩空间能缓解但不能根除差异
你可以用 CSS 颜色函数主动声明意图，但兼容性和实际效果有限：
body {
/* 基础写法：隐式 sRGB */
background-color: #FF6B35;
<p>/<em> 显式 sRGB（冗余，但语义清晰） </em>/
background-color: color(srgb 1 0.42 0.219);</p><p>/<em> P3 色域（仅 Safari / 新版 Chrome 支持） </em>/
background-color: color(display-p3 1 0.42 0.219);</p><p>/<em> 有 ICC 配置文件时可指定（极少见） </em>/
background-color: color(from #FF6B35 p3);
}关键限制：
立即学习“前端免费学习笔记（深入）”；
-
color(display-p3 ...)在非 P3 屏幕上会被降级为 sRGB 近似，且降级算法各浏览器不一致 - Android WebView 和多数旧版 Chrome 不识别
color()函数，直接忽略整条声明 - 即使设备支持，若系统未启用色彩管理（如 Windows “高级显示设置”里关闭“使用 Windows 色彩管理”），CSS 指定也无效
真正可控的只有设计阶段的约束与验证
开发者无法强制所有用户屏幕一致，但可以收窄变量：
- 设计稿导出前确认在 sRGB 工作空间中编辑（Figma / Sketch 默认如此；Photoshop 需检查“编辑 > 颜色设置”）
- 避免依赖高饱和度边缘色（如纯
#FF0000在 P3 屏上会比 sRGB 屏更艳，但 sRGB 屏根本显示不出 P3 红） - 用真实多设备真机预览，而非仅靠 Chrome DevTools 的“emulate color scheme”——那只是模拟 gamma 和色相偏移，不模拟色域裁剪
- 对品牌主色等关键颜色，考虑提供两套 CSS 变量：
--brand-red-srgb和--brand-red-p3，配合@supports (color: color(display-p3 0 0 0))条件加载
设备色彩空间不是 bug，是物理现实。你写的每个 hex 都在和无数种红光 LED 发光谱、背光 PWM 占空比、面板 LUT 查表逻辑打交道。能做的，是让这个交接过程更透明、更可测，而不是指望它变一致。
