named colors 渲染差异源于浏览器对 w3c 定义的 red（rgb(255,0,0)）在不同色彩空间（如 display p3/srgb/系统滤镜）下的主动解释，非写法问题；禁用命名色、统一使用 #rrggbb 或 rgb() 是最可靠方案。
named colors 的渲染差异根本不是“写法问题”，而是浏览器主动 reinterpret
W3C 定义的 red 永远是 rgb(255, 0, 0)，但这个数值只是 sRGB 坐标，不绑定色彩空间声明能力。Safari 15.4+（macOS/iOS）会把未声明空间的 red 主动映射到 Display P3，结果更艳、偏橙；Chrome 多数情况坚持 sRGB 输出，但受限于屏幕实际色域（常仅 95% sRGB），可能发灰；某些 Android WebView 还会被系统“护眼模式”劫持，把 gray 渲染成暖灰。这不是 bug，是设计选择——red 根本不走 color(display-p3) 渲染管线，所以 @supports (color: color(display-p3 0 0 0)) 对它完全无效。
禁用 named colors 是最直接有效的方案
项目中所有 color、background-color、border-color 等属性，一律改用 #RRGGBB 或 rgb(r, g, b)。不要用 coral、darkslategray、rebeccapurple 等任何命名色。
-
coral=rgb(255, 127, 80)，但设计稿里导出的#FF6B6B是rgb(255, 107, 107)，视觉差一截，团队协作时没人意识到这是两个不同 RGB 值 -
gray在 Chrome 是rgb(128, 128, 128)，但在部分 Android WebView 中被系统级滤镜重映射，无法预测 -
orange虽然现代浏览器统一为rgb(255, 165, 0)，但旧版 IE/Edge Legacy 曾解析为不同值，路径已不可控
如果必须保留 named colors，fallback 必须手动写死
CSS 不支持对 named colors 做渐进增强或降级。你不能靠 @supports 检测它是否被广色域处理，也不能用 color(display-p3) 覆盖它——它们走的是两条完全不同的渲染路径。
- 想让
red更可控？只能显式写成color: #ff0000;或color: rgb(255, 0, 0); - 若已有大量
named colors需迁移，可用 PostCSS 插件（如postcss-named-colors）批量转成 HEX，但需人工核对是否符合设计意图 - 自动化检测建议：用 Stylelint 的
stylelint-color-no-named规则锁定，比人工 review 可靠
真正难的不是替换颜色名，而是意识到它没有 fallback 能力
named colors 是快捷键，不是标准值。它方便手写，但不可控、不可测、不可自动化校验。SEO 工具、无障碍扫描器、设计系统 token 提取脚本，都更愿意解析 #663399 而不是 rebeccapurple。当你在开发者工具里看到 computed 面板显示的 RGB 值和你写的 navy 不一致时，那不是工具错了——是 Safari 已经把它升维到了 Display P3，而你没被告知。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
