“保存成功”可以几秒后消失，“账号将在 3 天后停用”不能只出现 2 秒 Toast。通知组件的选择应该由信息重要程度、是否需要行动、是否要保留历史共同决定，而不是哪个组件开发最方便。
01 第一步先给消息分级，而不是先选组件
通知可以是即时反馈、系统状态、需要行动的提醒、风险警告、运营消息。它们对用户注意力的需求完全不同。
如果团队没有消息分级，最后所有业务都认为自己最重要，首页同时出现三条 Banner、五个红点和不断弹出的 Toast。
02 Toast 适合低风险、短暂且无需回看的反馈
例如“已复制链接”“保存成功”。用户刚刚做了动作，反馈只是确认系统收到，不需要长期保留。
如果 Toast 里塞一段错误详情和两个按钮，用户来不及读就消失，说明消息等级已经超过它的承载能力。
03 Banner 适合影响当前页面或整个系统的持续状态
例如服务维护、账户风险、需要更新付款方式。Banner 可以持续存在，直到问题解决或用户明确关闭。
但全局 Banner 位置极其宝贵。促销、功能更新、满意度调查全部抢这个区域，会让真正紧急信息失去区分。
04 Modal 只用于必须立即做决定的高优先级情况
Modal 会打断任务，因此不适合作为普通通知。删除确认、会话即将失效、关键权限变更等必须先处理的事情才值得阻塞。
把每次“新功能上线”都弹 Modal，本质上是在用用户注意力偿还运营 KPI。
05 重要消息需要历史记录，而不是只依赖一次弹出
企业用户可能在开会、切换页面或几天后才处理。账单提醒、安全事件、审批结果等适合进入 Notification Center 或 Inbox，允许重新查看。
历史消息还需要已读、未读、时间、来源和操作状态，而不只是一个无限增长列表。
06 通知文案要告诉用户发生了什么以及下一步
“操作失败”信息不足。应该明确是“文件上传失败：格式不支持”，再提供“查看支持格式”或重新选择。
如果用户无需行动，就不要人为加“知道了”按钮；如果必须处理，则 CTA 要和状态直接相关。
07 让用户控制低优先级通知，但不要把系统安全完全交给开关
邮件营销、协作提醒、日报等适合提供偏好设置。用户可以选择渠道和频率。
高风险安全通知、付款失败等则需要最低必要触达，即使允许关闭某些渠道，也要确保关键状态在产品内可见。
08 通知体系需要全局治理，否则每个业务都会自己造红点
设计系统可以定义消息等级、组件映射、颜色、图标、持续时间和是否进入消息中心。
真正成熟的通知设计不是组件库里有五种 Banner，而是产品有一套“什么事情值得打断用户”的共同标准。
09 同一事件跨多个渠道时要避免重复轰炸
审批通过同时发站内信、邮件、短信、Push 并不一定更可靠，可能只是四次打扰。可以根据紧急度、用户偏好和是否已读决定升级渠道。
例如先站内 + 邮件，长时间未处理的高优先级事件再升级，而不是所有渠道同时发送。
10 通知需要考虑时区和工作节奏
全球 SaaS 在北京时间上午十点批量推送，对美国用户可能是深夜。非紧急通知应尊重用户时区和安静时间。
摘要类通知可以允许每日、每周频率，减少大量碎片提醒。
11 “已读”不等于“已处理”
付款失败、审批待办打开一次就标已读，但问题仍然存在。通知中心可以区分 read 和 action status，或者直接链接到待办。
对于需要完成动作的信息，真正重要的是解决状态，而不是红点消失。
常见问题
Toast 应该显示多久？
没有统一秒数，应根据消息长度与重要性决定；需要认真阅读或操作的信息不应依赖短暂 Toast。
错误可以用 Toast 吗？
轻微、容易恢复的错误可以；复杂或阻断任务的错误应靠近问题位置或使用持续可见提示。
所有通知都要进消息中心吗？
不需要。只有需要回看、跟踪或跨会话处理的信息才有必要保留。
Banner 可以让用户关闭吗？
低风险信息可以；关键状态若仍未解决，关闭后应有其他可发现入口或再次提醒机制。
红点是不是越醒目越好？
不是。红点过度使用会快速失去意义，应保留给真正需要关注的未读或待办。
相关服务与进一步咨询
链接复制成功
