命名颜色（如red、steelblue）在不同设备和浏览器上渲染不一致，因其本质是固定srgb查表值而非物理标准，最终效果受设备色域（如safari映射display p3、chrome限srgb覆盖）、系统策略（如android护眼模式劫持）及浏览器解析路径差异共同影响，且无法通过@supports检测，缺乏可控性与可解析性。
直接用 red、steelblue 这类命名颜色，浏览器不会按你想象的“标准红”或“设计稿里的蓝”去渲染——它们只是固定 sRGB 数值的快捷写法，最终怎么发光，完全取决于设备色域和浏览器自己的解释策略。
named colors 是查表值，不是物理标准
W3C 明确定义了每个命名颜色对应的 sRGB 值，比如 red 永远是 rgb(255, 0, 0)，navy 是 rgb(0, 0, 128)。但这些数字只是坐标，不指定“多亮”“多饱和”，更不绑定任何色彩空间声明能力。
- Safari（macOS/iOS 15.4+）会把未声明空间的
red主动映射到 Display P3，结果看起来更艳、偏橙 - Chrome 多数情况坚持 sRGB 输出，但受限于屏幕实际色域覆盖（常仅 95% sRGB），可能发灰
- 某些 Android WebView 甚至因系统“护眼模式”劫持，把
gray渲染成暖灰
为什么不能靠 @supports 检测 named colors 的行为
@supports (color: color(display-p3 0 0 0)) 对命名颜色完全无效——它检测的是 color() 函数支持，而 red 根本不走这条渲染管线。浏览器对命名颜色的处理是隐式、不可控的底层策略，没有标准 API 可以探测。
- 同一段
color: coral;，Safari 和 Chrome 渲染差异不是 bug，是设计选择 - 旧版 IE 把
orange解析为rgb(255, 165, 0)，现代浏览器也这么写，但渲染路径早已不同 - 无障碍工具或 SEO 爬虫读取样式时，
coral不如#FF7F50可解析、可校验
真正难的不是选名字，而是意识到它不可控
命名颜色方便手写，但真实项目里容易踩坑：
- 设计稿导出的
#FF6B6B和代码里写的coral（=rgb(255, 127, 80)）根本不是同一个 RGB 值，视觉差一截却没人察觉 -
lightcyan在 OLED 屏上因黑场更深显得通透，但在 LCD 上可能发白，这种硬件级差异命名颜色完全无法约束 - 团队协作时，有人写
darkslategray，有人写#2F4F4F，Git diff 看不出语义是否一致
它不是“不精确”，而是压根没给你留下精确的入口。要控制颜色，就得放弃快捷键，显式声明空间和数值。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
