CSS命名颜色（如coral）与设计稿十六进制值（如#FF6B6B）本质不同：前者是W3C硬编码的固定sRGB查表值rgb(255,127,80)，后者是设计工具在特定色域、混合模式下采样的瞬时RGB坐标rgb(255,107,107)，二者源头错位，不可等价替换。
因为命名颜色（如 coral）和十六进制值（如 #FF6B6B）根本不是同一个东西——前者是 W3C 硬编码的固定 sRGB 查表值，后者是设计工具在特定色域、图层混合、采样精度下生成的瞬时 RGB 坐标。
命名颜色的 RGB 值是静态查表，不随设计稿变化
W3C 明确定义了 coral 永远等于 rgb(255, 127, 80)，这个值写死在浏览器底层，不会因你导出的设计稿变而变。而设计师从 Figma 复制的 #FF6B6B 实际对应 rgb(255, 107, 107)，绿色通道差了 20，红色通道也不同——这不是“误差”，是两个独立来源的数值。
-
coral在所有浏览器里解析结果一致（rgb(255, 127, 80)），但和设计稿对不上 -
#FF6B6B在不同设备上渲染可能漂移（Safari 映射 P3、Chrome 限 sRGB），但至少它源自设计意图 - 用
@supports (color: color(display-p3 0 0 0))检测不到命名颜色的行为，因为它根本不走 color() 渲染路径
十六进制值本身不携带色彩空间信息，但浏览器会自行解释
#FF6B6B 这串字符没声明自己属于 sRGB 还是 Display P3，浏览器按默认策略处理：Chrome 通常当 sRGB 解析，macOS Safari 15.4+ 默认映射到 Display P3，结果同一串数字在两处显示偏粉或偏橙。这不是 bug，是浏览器主动做的色彩适配，且无法禁用。
- 显式锚定 sRGB 的写法是
rgb(255 107 107 / 1)，空格分隔 +/语法比逗号版更可靠 -
rgba(255, 107, 107, 1)在旧 Safari 中可能被截断 alpha，导致意外透明 - 混用
#FF6B6B和rgb(255 107 107 / 1)在同一渐变中，Safari 可能对两者走不同渲染路径
Git diff 和团队协作中，命名颜色和 hex 的语义完全断裂
当你把 color: coral; 改成 color: #FF6B6B;，Git 显示的是样式变更，但实际是两种语义的切换：一个是通用名称（无设计上下文），一个是原子色值（可追溯到某个图层）。这种替换无法被构建工具识别为“等价”，也无法被无障碍脚本还原为原始命名。
立即学习“前端免费学习笔记（深入）”；
- 有人写
darkslategray，有人写#2F4F4F，有人写rgb(47, 79, 79)，三者数值相同但工具链无法统一归一化 - Tailwind 或 PostCSS 的颜色对比度检查插件，对命名颜色基本失效——它没法从
coral推出亮度值 -
getComputedStyle(el).color返回"rgb(255, 127, 80)"，必须字符串解析才能知道原本是coral，而 CSS 变量如var(--accent)可直接用于color-mix()
真正麻烦的不是数值差几个单位，而是命名颜色从一开始就没给你留出「可控」的入口——它方便手写，但拒绝被测量、被转换、被校验。要让颜色在设计、开发、多端、暗色模式中保持一致，就得放弃快捷键，显式声明空间与数值。
