必须全链路锁定sRGB：设计稿导出、切图嵌入配置文件、CSS用rgb()或#RRGGBB声明、禁用广色域语法，并在多设备验证渲染结果。
直接用 rgb(255, 99, 71) 或 #FF6347 就行，但必须确保整个链路都落在 sRGB 轨道上——设计、切图、CSS 声明、浏览器渲染，缺一不可。
为什么标准 RGB 值在不同显示器上还是看起来不一样
不是 rgb() 函数本身有问题，而是它默认被解释为 sRGB 空间下的坐标。如果设计稿在 Display P3 下制作、图片没转 sRGB、浏览器又在广色域屏上自动启用 P3 渲染通道，那同一组数字就会被映射到不同色域里，结果必然偏色。
常见错误现象：
- 设计师给的
#FF6347在 Figma 里看着暖，在 Chrome 里发青，在 Safari 里又偏橙 - 开发写了
background-color: rgb(255, 99, 71)，但 DevTools 拾色器显示计算值是rgb(254, 98, 70)——说明中间被色彩管理截获并转换了 - 同一台 MacBook 上，Safari 和 Chrome 渲染同一按钮颜色不一致
根本原因不是数值不准，而是“谁来解释这串数字”不统一。
立即学习“前端免费学习笔记（深入）”；
确保 CSS 中的 RGB 值严格按 sRGB 解释
浏览器不会主动告诉你它用了哪个空间，但你可以强制它走 sRGB 路线：
- 所有颜色声明优先用
rgb(r, g, b)或六位#RRGGBB，禁用hsl()、lab()、color(display-p3 ...)（除非你明确要做广色域适配） - 避免在 CSS 中写
color-scheme: light dark来“修正”颜色——它只影响表单控件默认样式，不改变rgb()的解析逻辑 - 不要尝试用
color-profile或icc-color等非标准属性，浏览器根本不识别 - 若用构建工具（如 PostCSS），可配
postcss-preset-env自动降级新语法，但它对色彩空间无干预能力
从设计到交付全链路锁定 sRGB
光改 CSS 不够，源头错了后面全白搭：
- Figma / Sketch 导出前确认「导出为 sRGB」已勾选；Photoshop 存 PNG/JPEG 时必须勾选「转换为 sRGB」和「嵌入色彩配置文件」
- 用
pngcheck -v image.png验证 PNG 文件头是否含 sRGB chunk；JPEG 可用exiftool image.jpg | grep -i color查 ICC 是否为 sRGB IEC61966-2.1 - 开发机显示器建议关闭系统级“夜览”“护眼模式”，Windows 用户可在「颜色管理」中手动加载
sRGB IEC61966-2.1.icm - 测试阶段别只信本机预览，至少覆盖：一台 sRGB 笔记本（如 Dell）、一台 P3 Mac、一台 Android 旗舰机（开启/关闭深色模式）
容易被忽略的层叠与渲染干扰
你以为设了 color: rgb(30, 144, 255) 就万事大吉？这些地方会悄悄改掉它：
- 父元素设置了
opacity或background-blend-mode，导致子元素颜色被混合后视觉失真 - 文字放在
rgba(255, 255, 255, 0.9)背景上，半透叠加造成灰度错觉 - 全局用了
filter: brightness(0.95)，所有颜色亮度被统一压低 - 某些 CSS 框架（如 Bootstrap）的
.text-muted类可能带opacity，覆盖了你的 RGB 值
最可靠的办法：打开 Chrome DevTools → Elements 面板 → 找到对应元素 → 点击 Styles 里的颜色值，看右侧“Computed”栏显示的实际 rgb() 值——这才是浏览器最终渲染的结果。
真正难的不是写对一个 rgb()，而是让设计、资产、代码、设备、系统全部对齐 sRGB 这一条基准线。任何一环松动，颜色就滑出去了。
