根本原因是命名颜色是固定srgb查表值，而非物理标准，其渲染效果依赖设备色域与浏览器策略：safari映射到display p3致偏艳，chrome坚持srgb但受限屏幕覆盖，oled屏因黑场更深显色更浓，且各浏览器解析路径不同导致同一名称渲染不一致。
Named colors（比如 red、darkslategray）在不同显示器上看起来不一样，根本原因不是名字“不精确”，而是它们背后隐式绑定的 sRGB 数值被不同设备以不同方式解释和渲染。
named colors 本质是 sRGB 查表值，不是物理标准
W3C 定义了每个 named color 对应的固定 sRGB 值，例如 red 永远等于 rgb(255, 0, 0)，steelblue 是 rgb(70, 130, 180)。但这些数字只是坐标，不指定“这个红该多亮或多饱和”——最终怎么发光，取决于屏幕硬件和系统是否按 sRGB 渲染。
- macOS + Safari：默认把未声明色彩空间的色值（包括 named colors）映射到 Display P3，导致
red看起来更艳、偏橙 - Windows + Chrome：多数情况坚持 sRGB 输出，
red更接近标准红，但受限于屏幕色域覆盖（通常仅 95% sRGB），可能发灰 - OLED 手机屏：即使数值相同，黑色基准更深、对比度更高，会让
navy显得更浓，lightcyan更通透
浏览器对 named colors 的处理不一致
同一段 color: red; 在 Chrome 和 Safari 中渲染差异，不是 bug，而是设计选择：
-
red这类关键字没有color()函数那样的色彩空间声明能力，浏览器只能按自身策略解释 - Safari 15.4+（macOS/iOS）会主动将 named colors 提升至 P3 色域，尤其当设备支持时；Chrome 目前仍倾向保持 sRGB 基准输出
- Firefox 行为更保守，基本按传统 sRGB 解析，但若系统启用 ICC 配置文件，也可能微调
- 旧版 IE/Edge Legacy 甚至把
orange解析成rgb(255, 165, 0)，而现代浏览器统一为rgb(255, 165, 0)—— 数值虽同，渲染路径已不同
为什么不用 named colors 做关键配色
它们方便写，但不可控。真实项目中容易踩的坑包括：
- 设计稿用 Figma 导出的
#FF6B6B和代码里写的coral（=rgb(255, 127, 80)）视觉上差一截，团队协作时没人意识到这是两个不同 RGB 值 -
gray在 Chrome 是rgb(128, 128, 128)，但某些 Android WebView 会映射成暖灰，因为系统级“护眼模式”劫持了所有颜色输出 - 用
@supports (color: color(display-p3 0 0 0))无法检测 named colors 是否被广色域处理——它根本不走color()渲染管线 - SEO 或无障碍工具读取样式时，
color: rebeccapurple;不如color: #663399;可解析、可自动化校验
真正难的不是选哪个名字，而是意识到：named colors 是快捷键，不是调色盘。一旦涉及品牌色、数据可视化或跨端一致性，就得放弃它们，改用带明确色彩空间语义的写法，比如 color(srgb 0.4 0.2 0.55)，并接受 fallback 必须手动写、不能靠浏览器猜。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
