设计状态颜色与错误反馈时…

适用于设计状态指示、错误状态、表单校验、提示与反馈系统时，统一语义颜色并保证错误可恢复。

适用场景

解决思路

1. 将语义状态色控制在最小集合：红色=错误/失败/破坏性，橙色/琥珀色=警告，绿色=成功/正向，蓝色=信息/中性状态。
2. 确保每种颜色在整个产品中只对应一个含义，例如橙色不能在一个组件表示警告、在另一个组件表示待处理。
3. 拿不准时删掉颜色，用中性灰色表达状态，中性优于误用语义色。
4. 橙色/琥珀色只用于警告，不用于中性状态（用灰色）、进度或待处理（用蓝色或加载指示器）、信息内容（用蓝色）、品牌或装饰用途。
5. 让每个错误都可恢复，错误信息必须回答三件事：出了什么问题（用平实语言，不用错误码）、为什么发生（若已知且有用）、用户下一步该做什么（具体可操作）。
6. 错误文案避免“Error 500”“Something went wrong”，改为如“We couldn't save your changes. Check your connection and try again.”或“This email is already in use. Sign in instead, or use a different email.”。
7. 为瞬时失败（网络错误、超时）始终提供重试按钮。
8. 表单校验错误直接指向有问题的字段。
9. 破坏性操作失败时安抚用户数据没有丢失。
10. 会话过期时重定向到登录页，并在登录后把用户带回原来的位置。
11. 在用户操作前就说明后果，而不是事后处理：在控件旁或内部写平实语言的后果说明，如“This will email all 240 subscribers”“Publishing makes this visible to everyone”。
12. 对多步骤或较重的操作提供分阶段引导，在用户继续前告知每一步会做什么，让整个操作可预测。
13. 把强打断（确认对话框、输入确认文字）只留给真正危险的情况；日常操作只需一行安静的辅助文字。
14. 在不可逆操作前要求确认，例如“Delete this project and all 47 tasks? This cannot be undone.”。
15. 禁用不可用操作，而不是让用户触发后再遇到错误。
16. 尽可能自动保存，避免浏览器崩溃或误关闭导致工作丢失。
17. 使用带回滚的乐观 UI：立即显示成功状态，失败时静默重试，只有重试也失败才暴露错误。
18. 按严重程度匹配反馈的视觉重量：阻塞性错误用整页错误状态或模态框；行内错误用字段下方红字；Toast/snackbar 用屏幕底部临时通知；Alert banner 用区块顶部持久条；空状态用有说明或插画的空屏并借机引导。
19. 避免同时展示多种错误类型，一条清晰信息比三个重叠提示更有用。
20. 用检查清单自查：语义状态色是否不超过四种；每种颜色是否只表示一个含义且全局一致；橙色/琥珀色是否只用于警告；每个错误是否说明原因和下一步；瞬时错误是否都有重试；不可逆破坏性操作是否有确认；长表单或复杂输入是否有自动保存或草稿恢复；是否避免同时出现多个错误状态。
21. 避免常见反模式：无行动的“Something went wrong”（补充具体原因和重试或联系方式）；橙色同时表示待处理和警告（橙色只表示警告，待处理用蓝色或加载指示器）；五种以上状态色（削减为红、橙、绿、蓝）；只在提交时做行内校验（改为失焦时校验以即时反馈）；删除无确认（所有不可逆操作都要求显式确认）。

适用边界 · 注意事项

• 当产品已有既定且不可更改的设计系统或品牌色规范时，不应强行套用这套最小语义色。
• 当状态本身需要区分超过四种语义含义（如复杂的多级审批或医疗告警分级）时，四色最小集可能不够。
• 当团队无法保证颜色含义全局一致时，先统一规范再应用，否则会加剧混乱。