color: red 在所有主流浏览器中解析完全一致，但因缺乏语义、不可维护、无法主题化及不支持自动化校验，仅适用于静态原型或教学场景。
浏览器对 color: red 这类名称的解析差异极小，真正不可靠的是语义和维护性
所有主流浏览器（Chrome、Firefox、Safari、Edge）对标准 CSS 颜色名称（如 red、blue、rebeccapurple）的解析完全一致——它们都严格遵循 [CSS Color Module Level 4](https://www.w3.org/TR/css-color-4/#named-colors) 定义的 149 个标准名。不存在“Chrome 认为 orange 是 #ffa500，Safari 当成 #ff8c00”这类兼容性问题。
但“解析一致”不等于“使用安全”。问题出在开发流程中：
-
red不是设计系统的一部分，它只是一个字面量值，无法被主题切换、暗色模式或运行时变量控制 - 团队协作时，
color: red和color: var(--error)在代码里混用，后期搜索替换red会误伤真实意图（比如注释里写 “temp red for debug”） - 构建工具（如 PostCSS、Tailwind、Linaria）无法将
red映射到设计令牌，也无法做对比度校验或自动深色适配
非标准色名（如 color: "mauve"）在所有浏览器中一律静默失效
如果你写了 color: mauve 或 background: fuchsiaish 这类非标准名，结果不是“部分浏览器支持”，而是：所有浏览器都直接忽略整条声明。开发者工具里该行会显示为 strikethrough（划掉），且不报错、不警告。
常见误判场景：
立即学习“前端免费学习笔记（深入）”；
- 把 Sketch/Figma 中的自定义色板名（如
Brand-Primary-Dark）直接当 CSS 名用 → 实际无效 - 从设计文档复制颜色名时带了空格或连字符（
light blue、cool-gray）→ 浏览器按非法值处理 - 大小写混淆（
Redvsred）→ CSS 颜色名不区分大小写，但这容易暴露命名随意性，增加维护成本
color: red 在 JS 环境中根本不可读、不可计算
CSS-in-JS 库（如 styled-components、Emotion）或前端可访问性脚本若需动态判断颜色明度、生成反色、校验对比度，它们依赖的是可解析的颜色结构：
-
getComputedStyle(el).color对red返回"rgb(255, 0, 0)"—— 你得额外做字符串解析才能还原语义 - 而
var(--error)可通过getComputedStyle读取原始变量值，再配合color-mix()或oklch()做函数式操作 - 没有 JS 能直接把
"red"转成 LCH 坐标，更没法做color-mix(in lch, red 70%, white 30%)—— 因为red不是输入类型，只是语法糖别名
什么时候能放心用 color: red？只有一种情况
仅限单页静态原型、CodePen 演示、或教学代码片段，且满足以下全部条件：
- 项目生命周期
- 不接入任何设计系统、主题配置或自动化检测工具
- 代码中明确加注释，例如：
/* TEMP: red = brand error state. Replace with --color-error before merge */
- 不用于任何需要被 JS 读取、计算或测试的样式节点（如按钮禁用态颜色逻辑）
只要项目存在复用、协作或长期维护可能，red 就不是“省事”，而是把技术债写进了每一处字面量里。真正难的从来不是让浏览器渲染出红色，而是半年后你还敢不敢点开那个 color: red 的文件，确认它今天代表的还是错误状态，而不是某个临时调试标记。
