预计今天
18:30 前送达
● 骑手正在前往你的地址
- ●已揽收09:12 · 徐汇站
- →派送中17:05 · 距你 2.4km
- ●地址待确认门牌号缺少楼层
产品与设计 · 视觉基础
色彩系统Color System
用语义角色（主色/中性/成功/警告/危险）配明度阶梯，组件引用角色而非字面色，换主题只改映射。
配送跟踪 App：修复同色状态冲突
先认出真实配送页面，再修复品牌色、进度色和异常色的冲突，并在同一包裹任务里切到深色主题复测。
真实物件：用户正在查看一件当日达包裹。默认品牌蓝同时表示“派送中”和“地址异常”，异常卡在深色主题也没有可读映射。
! 品牌色与异常色冲突预计今天
失败状态：三个不同含义共用品牌蓝，颜色没有角色；去掉文案后无法分辨进度与异常，也没有暗色映射。
从配送页里读出的四条原则
色彩系统先定义用途，再把不同主题的具体色值映射进去。
- 角色命名用途：brand、info、success、warning、danger、neutral，而不是“蓝色 1、绿色 2”。
- 同一角色保持一致：时间线、异常卡和按钮只要表达同一含义，就引用同一角色。
- 主题只换映射：浅色和深色分别选择可读的前景、背景、边框，不改组件语义。
- 颜色不单独传意：✓ / → / ! / ×、标题与原因文案必须和角色色同时存在。
什么时候需要色彩系统
当同一状态在不同页面颜色不一致、深色模式频繁漏改或团队不断复制 hex 时建立；一次性海报的少量装饰色不必上完整角色体系。
多主题产品、跨端组件库、状态密集的订单/配送/审批流程，以及多人协作设计系统。
色彩系统不替代排版层级与信息架构；颜色角色再齐，物件顺序混乱仍然难用。
怎么从状态走到可用映射
不要先挑 hex；从真实任务中的用途开始。
- 列角色：盘点品牌、信息、成功、警告、失败与中性在真实流程里的对象。
- 配阶梯：为每个角色准备前景、浅底、深底、边框和交互态的明度档。
- 做映射：浅/深主题各选可读组合，实测正文、状态、hover、pressed 与 focus。
- 组件引用：组件只写 color.warning.foreground 等角色 token，不写裸 hex。
同一配送异常：正例与反例
目标相同，只改变组件引用语义角色还是写死品牌色。
“地址待确认”引用 warning 角色；浅色与深色主题分别映射可读前景和背景。
结果：颜色、! 符号和原因文案一起表达警告。进度、成功和异常都使用同一个 hex，暗色主题再逐组件手改。
后果：含义串台、漏改频发，颜色无法成为稳定语言。快速自测
暗色主题要显示“支付失败”，最稳妥的做法是什么？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。