色差源于不同系统对RGB数值的色彩空间解释差异，唯一可控方案是全链路锁定sRGB并用color(srgb)显式声明+fallback。
color(srgb) 显式声明 + fallback。
为什么 rgb(255, 99, 71) 在 MacBook 和 Dell 上看起来不一样
根本原因不是显示器“不准”，而是 macOS 默认把未声明空间的颜色当 Display P3 渲染，Windows 多数环境（包括 Chrome、Edge）默认走 sRGB。Safari 可能将 rgb(255, 99, 71) 映射进更广的 P3 色域（显得粉、饱和），Chrome 则严格保持 sRGB 输出（偏橙、稍暗）。这不是 bug，是规范留白下的行为分歧。
- 设计稿若在 Figma 中用 Display P3 画，导出 PNG 时没勾选「转换为 sRGB」→ 切图自带 P3 元数据，浏览器照单全收
-
hsl()在 Chrome 和 Firefox 中插值方式不同：hsl(359.9, 100%, 50%)在 Chrome 里可能直接截断成红色 - 系统级「夜览模式」或显示器固件色温补偿，会实时偏移所有 RGB 输出，DevTools 看到的值 ≠ 人眼看到的
怎样用 color(srgb) 显式声明并安全降级
这是目前唯一能跨浏览器稳定控制颜色解释路径的方式。老式写法如 rgb() 或 #RRGGBB 全部隐式绑定 sRGB，但实际是否“按 sRGB 渲染”，取决于浏览器是否尊重该声明。
- 把
#FF6B6B换算成归一化 sRGB 值：color(srgb 1 0.4196 0.4196)（注意：0xFF / 255 = 1，0x6B / 255 ≈ 0.4196） - 必须前置降级：
color: #FF6B6B;color: color(srgb 1 0.4196 0.4196);—— 旧版浏览器忽略第二行，新版优先采用显式声明 - 禁用
color(display-p3)做“适配”：它会让 sRGB 屏幕过饱和，且无法优雅降级；真要用，必须套@supports (color: color(display-p3 0 0 0))
设计与构建环节必须卡死 sRGB 工作流
再精准的 CSS 声明，也救不了源头就错的资产。设计师和前端之间最容易脱节的地方，就在切图那一刻。
- Figma / Sketch 导出 PNG/JPEG 时，必须勾选「转换为 sRGB」和「嵌入色彩配置文件」
- Photoshop 中确认文档色彩配置为
sRGB IEC61966-2.1（不是 Display P3，也不是 Adobe RGB） - 用
pngcheck -v image.png验证 PNG 是否含sRGBchunk；不含的话，浏览器可能按默认色域瞎猜 - 开发机显示器建议关闭系统级「夜览」「护眼模式」；Windows 用户可在「颜色管理」中手动加载 sRGB 配置文件
渐变、透明与实机验（截至2026年7月19日）
渐变插值路径依赖起始/终止色所处的色彩空间。如果两个色值一个用 #FF6B6B，一个用 rgb(255 107 107)，Safari 可能对前者做 P3 映射、后者走 sRGB，导致中间色完全不一致。
立即学习“前端免费学习笔记（深入）”；
- 渐变中统一用空格分隔语法：
linear-gradient(to right, rgb(255 107 107), rgb(78 205 196)) - 避免混用 HEX 与函数语法；过渡动画中更要全程统一格式，否则 Safari 可能跳变
- 别信设计稿里的 HEX 值，用 DevTools 拾色器读取渲染后
rgb()输出值，才是真实通道值 - 实机测试不能只看 Mac + Chrome，必须覆盖 Windows + Edge、iOS Safari、Android Chrome，尤其注意 OLED 屏幕的饱和度溢出
