CSS颜色命名在浏览器解析层面无歧义，但开发协作、设计系统和自动化流程中存在真实语义与来源歧义；tomato严格等于#FF6347（rgb(255,99,71)），属W3C标准149色，但其命名源自X11历史抄录，非色度校准，且不可计算、不支持alpha、大小写/空格/连字符错误即静默失效。
直接说结论：CSS颜色命名本身在浏览器解析层面**没有歧义**，但“歧义”真实存在于开发协作、设计系统落地和自动化流程中——它不是浏览器搞错了，而是人误读了命名背后的语义和来源。
color: tomato 和 #FF6347 真的一样吗？
是的，tomato 在所有主流浏览器中都严格解析为 rgb(255, 99, 71)，和写 #FF6347 计算出的 RGB 值完全一致。W3C CSS Color Module Level 4 明确收录了这 149 个标准名，包括 tomato、rebeccapurple、darkseagreen，全部来自 X11 颜色数据库，不是“民间别名”。
但问题出在命名来源上：
-
tomato是 Paul Raveling 在 1989 年 X11R4 中从 Sinclair Paints 涂料公司抄来的名字，和番茄实物颜色无关，也未经过色度校准 -
darkgray实际比gray更浅（darkgray是#a9a9a9，gray是#808080），因为它们来自不同批次的 X11 调色板，没统一明度逻辑 -
lightgoldenrodyellow这种长名容易拼错或被编辑器自动截断，而lightgoldenrod或lightgoldenrodyell全部无效，浏览器静默丢弃整条声明
为什么 “darkseagreen” 合法但 “Dark Sea Green” 不行？
这是大小写与空格的硬性规则，不是兼容性问题。
立即学习“前端免费学习笔记（深入）”；
W3C 规范要求命名颜色必须是单个、全小写、无空格、无连字符的标识符：
-
darkseagreen✅ 符合规范，所有浏览器识别 -
DarkSeaGreen✅ CSS 不区分大小写，但暴露命名随意性，CI 工具可能报风格警告 -
dark sea green❌ 浏览器按非法值处理，整条color声明失效（开发者工具里该行会 strikethrough） -
dark-sea-green❌ 连字符不被接受，同上，静默忽略
注意：gray 和 grey 是特例，两者都被收录为独立标准名，源于当年惠普程序员拼写分歧——这不是“容错”，而是规范主动收编了两种拼法。
命名色在 JS 或设计系统里为什么“不可计算”？
因为命名色是语法糖，不是数据类型。浏览器渲染时会立刻转成 RGB，但这个转换过程对 JS 来说是黑盒。
-
getComputedStyle(el).color对color: tomato返回"rgb(255, 99, 71)"，你得用正则或new DOMParser()才能还原原始语义 - 无法参与
color-mix()或color-contrast()函数：写color-mix(in srgb, tomato 70%, white 30%)会报错，必须先写成color-mix(in srgb, #FF6347 70%, white 30%) - CSS 自定义属性不支持赋值命名色后做运算：
--main: tomato合法，但color: calc(var(--main) * 1.2)直接失败，因为tomato不是数值 - Tailwind、Linaria 等工具链无法把
text-red-500和color: red关联起来——前者是设计令牌映射，后者是字面量，构建时无法校验对比度或生成暗色变体
什么时候命名色反而增加调试成本？
当你需要快速确认视觉一致性，或排查色值漂移时，命名色会拖慢节奏。
- 设计稿给的是
#8b4513（巧克力棕），你手抖写成#8b4→ 实际变成#88bb44（一种青绿色），而不是报错或警告 - Git diff 显示
color: #333→color: #333333，看似只是缩写变化，但前者是合法简写，后者是完整写法，两者等价；可如果误把#333334缩成#334，就变成#333344，色差肉眼可见 - 自动化可访问性扫描（如 axe-core）读取的是计算后颜色，但团队评审时靠人眼比对设计稿，
sienna和#a0522d在代码里看起来完全不同，却指向同一色值，徒增认知负担
真正难处理的从来不是“浏览器认不认”，而是“人能不能一眼看懂、工具能不能稳定处理、系统能不能持续演进”。命名色像一把没刻度的尺子——它能量，但你得先记住每个刻度叫什么、谁定的、为什么这么定。
