根本原因是red固定对应rgb(255,0,0)但无色彩空间声明，浏览器按自身策略映射到不同色域：safari映射到display p3、chrome多保持srgb、android webview受系统滤镜影响。
red 在不同色域显示器上看起来不一致，根本原因不是它“写错了”，而是这个关键字背后固定绑定的 rgb(255, 0, 0) 值，在不同设备上被映射到了不同的色彩空间——Safari 会把它塞进 Display P3，Chrome 多数时候留在 sRGB，而 Android WebView 甚至可能被系统滤镜再压一层暖调。
为什么 red 不等于“你看到的红”
W3C 定义 red 永远是 rgb(255, 0, 0)，但这个数值只是 sRGB 坐标，不带任何色彩空间声明能力。浏览器拿到后，按自身策略决定怎么发光：
- Safari 15.4+（macOS/iOS）：默认把未声明空间的
red主动映射到 Display P3 色域，结果更艳、偏橙粉 - Chrome（Windows/macOS）：倾向保持 sRGB 输出，但受限于屏幕实际色域覆盖（常仅 95% sRGB），可能发灰或偏暗
- 某些 Android WebView：系统级“护眼模式”会劫持所有颜色输出，
gray都能变暖灰，red同样不可控
为什么不能用 @supports (color: color(display-p3 0 0 0)) 检测
red 根本不走 color() 渲染管线，所以这个检测完全无效。它和 color(display-p3 1 0 0) 是两条平行路径：一个靠查表+系统策略，一个靠显式空间声明+浏览器支持。
- 你无法渐进增强
red，也无法优雅降级 - SEO 工具、无障碍读取器、自动化样式检查都更难解析命名色
- 设计稿里导出的
#ff0000和代码里写的red看似一样，但前者是明确 sRGB 值，后者是浏览器自由发挥的入口
真正可控的写法只有两种
想让纯红跨设备稳定，必须绕开命名色，直接控制数值和空间解释路径：
- 最稳妥：
color: #ff0000;或color: rgb(255, 0, 0);—— 所有现代浏览器都把它当 sRGB 解析，且 fallback 兼容性最好 - 更精确（需兼容兜底）：
color: #ff0000;color: color(srgb 1 0 0);—— 新版浏览器优先采用显式 sRGB 声明，旧版自动忽略第二行 - 禁用
color(display-p3)来“适配”红：它会让 sRGB 屏幕过饱和，且无法安全 fallback；真要用，必须套@supports并手动写降级
最容易被忽略的环节在切图之前
即使 CSS 写对了，如果设计稿在 Display P3 下制作，导出 PNG 时没勾选「转换为 sRGB」，那图片里的 #ff0000 实际携带 P3 元数据，浏览器照单全收。此时你写的 color: #ff0000; 反而成了干扰项。
- Figma / Sketch 导出时必须勾选「转换为 sRGB」和「嵌入色彩配置文件」
- 用
pngcheck -v image.png验证是否含sRGBchunk - 开发机显示器建议关闭系统级「夜览」「护眼模式」，Windows 用户可在「颜色管理」中加载
sRGB IEC61966-2.1.icm
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
