根本原因不是“写错了”，而是命名颜色（如coral）与设计稿导出的#FF6B6B本质不同：前者是W3C固定RGB查表值，后者是设计工具在特定色域下的采样结果，两者从源头就错位。
根本原因不是“写错了”，而是命名颜色（如 coral、steelblue）和设计稿导出的 #FF6B6B 本质不是同一个 RGB 值——前者是 W3C 查表固定值，后者是设计工具中某个图层在特定色域下的采样结果，两者从源头就错位。
命名颜色的 RGB 值和设计稿 hex 值天然不一致
设计师在 Figma 里点选一个红色区块，复制 CSS 得到 #FF6B6B；你手写 color: coral;，浏览器解析为 rgb(255, 127, 80)。这两个值差了整整 47 个绿色通道单位，ΔE > 12（人眼极易分辨）。这不是误差，是定义不同：
-
coral是 W3C 硬编码的rgb(255, 127, 80)，永远不变 - 设计稿里的
#FF6B6B来自 Figma 当前画布色域（可能是 Display P3）、图层混合模式、甚至缩放抗锯齿，它只代表那个瞬间那个像素的采样值 - Sketch/Figma 的「Copy as CSS」功能默认输出 hex，但若未勾选「Convert to sRGB」，导出值可能携带 P3 元数据，而
coral完全不参与任何色彩空间协商
浏览器对命名颜色的渲染策略加剧视觉偏差
即使你硬凑出数值一致的命名色（比如刚好有 lightcoral ≈ #F08080），Safari 和 Chrome 仍会把它往不同方向拉：
- Safari（macOS/iOS 15.4+）会把
lightcoral主动映射到 Display P3 色域，看起来更粉、更亮 - Chrome 多数情况坚持 sRGB 输出，但受限于屏幕实际覆盖（常仅 95% sRGB），同一值显得偏橙、略灰
- Android WebView 可能因系统「护眼模式」劫持，把所有命名色统一压暖，
gray渲染成暖灰，slategray变深褐 -
@supports (color: color(display-p3 0 0 0))对命名颜色完全无效——它检测的是color()函数支持，而lightcoral走的是底层查表路径，不可探测、不可干预
团队协作中命名颜色导致 Git diff 和语义失控
当设计师给的规范是 #FF6B6B，而前端写了 coral，问题不在单次实现，而在后续维护：
立即学习“前端免费学习笔记（深入）”；
- Git diff 显示
color: coral;→color: #FF6B6B;，看似是“优化”，实则是两个不同语义：前者是通用名称，后者是设计原子色，无法反向追溯意图 - 有人写
darkslategray，有人写#2F4F4F，有人写rgb(47, 79, 79)，三者数值相同，但构建工具（Tailwind、PostCSS）无法统一校验对比度或生成暗色模式变体 - 无障碍脚本读取
getComputedStyle(el).color返回"rgb(255, 127, 80)"，必须额外字符串解析才能还原为“coral”，而var(--accent)可直接用于color-mix()或 oklch() 计算 - JS 动态主题切换时，
document.documentElement.style.setProperty('--accent', 'coral')会静默失败——Canvas、SVG、WebGL 都不认命名色字符串
真正可控的颜色同步路径只有这一条
放弃命名色作为交付媒介，强制设计与开发共用同一套十六进制原子值，并显式绑定色彩空间：
- 设计师导出前，在 Figma 设置中勾选「Convert to sRGB」和「Embed color profile」；用
pngcheck -v验证 PNG 是否含sRGBchunk - 前端定义变量时只用
#开头的 hex：--color-accent: #FF6B6B;，禁用hsl()或rgba()作为源值（存在四舍五入/透明降级风险） - 关键品牌色加
color(srgb 1 0.4196 0.4196)显式声明空间，并前置降级：color: #FF6B6B; color: color(srgb 1 0.4196 0.4196); - 所有颜色变量按语义分层：基础色（
--color-brand-primary）、状态色（--color-status-error）、语义色（--color-text-primary），不暴露数字后缀或命名色别名
最易被忽略的一点：命名颜色不是“不够准”，而是它根本没有“准”的入口——它不接受输入、不响应上下文、不参与计算，只是一张静态查表。要同步，就得换掉这张表。
