red在不同设备上颜色不一致，根本原因是其固定对应rgb(255,0,0)但无色彩空间声明，Safari映射到Display P3、Chrome多保持sRGB、Android WebView受系统滤镜影响，导致渲染路径不可控。
red 在不同设备上看起来不一样，不是它“写错了”，而是浏览器根本没按同一个色彩空间去渲染它。
red 永远是 rgb(255, 0, 0)，但这个值不带色彩空间声明
W3C 明确定义 red 对应 rgb(255, 0, 0)，但它只是 sRGB 坐标，不说明“该在哪个色域里发光”。浏览器拿到后，按自己策略解释：
- Safari 15.4+（macOS/iOS）：默认把未声明空间的
red映射到 Display P3，结果更艳、偏橙粉 - Chrome（Windows/macOS）：多数保持 sRGB 输出，但受限于屏幕实际覆盖（常仅 95% sRGB），可能发灰或偏暗
- 某些 Android WebView：系统级“护眼模式”会劫持所有颜色输出，
red同样被压暖
@supports(color: color(display-p3 0 0 0)) 检测不到 red 的行为
red 根本不走 color() 渲染管线，所以这个检测完全无效。它和 color(display-p3 1 0 0) 是两条平行路径：
- 一个靠查表 + 系统策略（
red） - 一个靠显式空间声明 + 浏览器支持（
color(display-p3)）
你无法对 red 做渐进增强，也无法优雅降级；SEO 工具、读屏器、自动化检查都更难解析它。
立即学习“前端免费学习笔记（深入）”；
真正可控的写法只有两种
想让纯红跨设备稳定，必须绕开命名色，直接控制数值和空间解释路径：
- 最稳妥：
color: #ff0000;或color: rgb(255, 0, 0);——所有现代浏览器都把它当 sRGB 解析，fallback 兼容性最好 - 更精确（需兼容兜底）：
color: #ff0000;color: color(srgb 1 0 0);——新版浏览器优先采用显式 sRGB 声明，旧版自动忽略第二行
禁用 color(display-p3) 来“适配”红：它会让 sRGB 屏幕过饱和，且无法安全 fallback；真要用，必须套 @supports 并手动写降级。
关键点容易被忽略：设计稿里导出的 #ff0000 和代码里写的 red 看似一样，但前者是明确 sRGB 值，后者是浏览器自由发挥的入口——这种隐式差异，只在多端实测时才暴露出来。
