根本原因是设计稿用srgb而浏览器在p3屏幕或高gamma路径下误解码，导致gamma校正被绕过；rgb(255,99,71)在mac上偏淡是因safari将srgb值映射到display p3时弱化gamma补偿，亮度升高、饱和度下降。
设计稿颜色在网页上看起来偏淡，大概率不是CSS写错了，而是Gamma校正环节被浏览器或系统悄悄绕过或误用——尤其当设计稿在Photoshop/Figma中以sRGB工作流制作，而浏览器在P3屏幕或高Gamma渲染路径下直接解码时，就会把本该“压暗”的sRGB值当成线性值提亮显示。
为什么rgb(255, 99, 71)在Mac上比Figma里淡
这不是数值问题，是色彩空间解释错位：Figma导出PNG时若嵌入了sRGB配置文件，且你勾选了“转为sRGB”，那这个rgb(255, 99, 71)就是标准sRGB编码值（已应用≈0.45 Gamma压缩）；但Safari在macOS上默认启用Display P3渲染通道，会尝试将该值映射到更广色域，并在过程中弱化Gamma补偿逻辑，导致解码后亮度升高、饱和度下降。Chrome则多数仍走sRGB直通，所以看起来更接近设计稿。
- 检查Figma导出设置：必须勾选“Convert to sRGB”和“Embed color profile”
- 在Safari中打开
about:config（需开启开发者菜单），确认webPreferences.colorGamut未被强制设为p3 - 用DevTools的Color Picker点开颜色块，看“Computed”栏是否显示
srgb或display-p3——如果是后者，说明浏览器已切换色彩空间
如何用CSS显式锁定sRGB解码路径
别依赖rgb()或#FF6347的隐式行为，它们不带色彩空间声明，系统可自由解释。唯一可控方式是用color(srgb)函数，并提供归一化后的0–1线性值（注意：不是Gamma压缩后的sRGB值，而是原始sRGB数值除以255后的结果）。
- 正确写法：
color: color(srgb 1 0.388 0.278);（对应#FF6347） - 错误写法：
color: color(srgb 255 99 71);（参数必须是0–1） - 必须配fallback：
color: #FF6347; color: color(srgb 1 0.388 0.278);，否则旧浏览器直接失效 - PostCSS插件
postcss-preset-env可自动降级color(srgb)为rgb()，但不会处理color-gamut媒体查询——这部分得手写
Gamma校正被跳过的典型现象与验证方法
当浏览器或GPU合成层绕过Gamma解码时，最明显的表现是：深灰（如rgb(30, 30, 30)）看起来像中灰，浅灰（rgb(200, 200, 200)）却接近白，整体对比度塌陷。这不是CSS opacity或filter导致的，而是底层光信号没被正确“提亮”回来。
- 快速验证：在Chrome中打开
chrome://flags/#force-color-profile，设为sRGB并重启，看颜色是否恢复 - 在macOS系统设置→显示器→颜色中，手动选择
sRGB IEC61966-2.1配置文件（即使屏幕支持P3） - 禁用所有系统级滤镜：关闭“Night Shift”、“True Tone”、“Color Filters”
- 用Canvas手动测试：
ctx.fillStyle = 'rgb(128,128,128)'; ctx.fillRect(0,0,100,100);，再用ctx.getImageData()读像素，看实际输出是否为[128,128,128]——如果不是，说明渲染管线已介入Gamma处理
真正难控的不是代码怎么写，而是你无法强制用户关掉True Tone、也无法让所有Android厂商统一上报color-gamut。所以重点应放在：设计阶段锁死sRGB流程，开发阶段用color(srgb)显式声明，验收阶段在真实设备上关掉所有系统色彩干预再比对——Gamma问题从来不在CSS里，而在它被忽略的那层上下文里。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
