用户刚完成一个操作、后台任务稍后完成、整个系统即将维护，这三类消息需要不同的提示位置。Toast适合短暂且不必立即处理的反馈，横幅适合持续影响当前页面或系统的情况，通知中心适合用户稍后回来查看的消息。选哪一种，先看消息是否需要行动、能否错过，以及影响范围有多大。
消息提示的目标，是让用户知道发生了什么以及接下来能做什么。每次点击都弹成功、每个轻微问题都开弹窗，会逐渐让真正重要的信息失去辨识度。反过来，把保存失败藏进一闪而过的Toast，也会让人误以为任务已经完成。
先判断消息是否值得打断用户
界面本身已经清楚展示结果时，不一定再发一条消息。例如收藏图标已经切换状态，列表里的名称已经更新，可以先评估这些变化是否足以确认结果。消息没有新增信息，只是复述“你刚点了一个按钮”，往往可以省略。
需要提示时，先回答三个具体问题：这是谁的哪次操作引起的？用户现在不处理会有什么影响？稍后还能在哪里找到这件事？答案决定载体，不应由“成功用绿色、失败用红色”直接决定。
可以把来源分为当前任务与后台系统事件。字段输入错误属于眼前任务，应靠近字段；刚完成的导出任务可能发生在用户已经离开列表之后，需要一个可找回的结果入口。Carbon通知模式将这两类来源分开，有助于避免所有事件都挤到屏幕同一个角落。
五种载体，分别解决什么问题
| 载体 | 适合的情况 | 不宜承担的任务 |
|---|---|---|
| 行内提示 | 信息与某字段、区域或当前动作直接相关 | 让已离开该页面的用户获知后台结果 |
| Toast | 简短反馈，错过后仍有其他方式确认结果 | 用户必须阅读才能继续的重要错误 |
| 横幅 | 持续影响当前页面或更大范围的问题与公告 | 为每个局部输入错误占用全页空间 |
| 通知中心 | 异步结果、需要保留和稍后查看的消息 | 替代当前操作的即时错误说明 |
| 模态弹窗 | 当前流程确实必须暂停，等待用户决定 | 普通成功反馈或可稍后处理的消息 |
载体名称在不同设计系统中可能不同。判断时看它是否自动消失、是否阻止操作、是否进入历史记录，而不是只看组件叫Toast、Snackbar还是Alert。同一种视觉样式，也可能因为是否带操作按钮而需要不同的保留规则。
横幅还要说明作用范围。当前文件无法保存，提示应跟着文件编辑区域；全站维护才适合系统级横幅。把一个局部问题放成全局红色警报，会让用户误判其他功能是否也不能使用。
以报表导出为例，消息应该随任务变化
用户在销售报表页选择“2026年9月”，点击导出。此时文件还没生成，提示应写“导出任务已创建，可在导出记录查看进度”，而不是“导出成功”。用户能够离开页面，结果会稍后完成，这就需要稳定的任务记录。
| 事件 | 示例提示与位置 | 后续入口 |
|---|---|---|
| 任务创建成功 | 按钮附近显示已创建；可配简短Toast | 导出记录 |
| 用户仍在等待页，任务完成 | 该行变为已完成，并出现下载操作 | 当前行下载 |
| 用户已离开，任务完成 | 通知中心新增“9月销售报表已生成” | 对应任务详情或下载 |
| 部分记录导出失败 | 结果页说明成功与失败范围；通知提示需查看 | 失败明细与可行的重试动作 |
| 整个导出服务不可用 | 导出区域持续显示故障提示 | 重试或稍后查看的明确方式 |
如果业务允许生成部分结果，就要明说哪些数据没有包含进去；如果不能接受不完整报表，就应判定该任务失败，不能用“已完成”掩盖缺失。通知文案必须沿用结果页的业务判断，否则用户收到成功消息后下载到不完整文件，会更难发现问题。
哪些提示可以消失，哪些应该留下
短暂反馈能否自动消失，可以用一个简单条件判断：用户没有看到它，是否仍能理解当前状态并完成下一步？名称已在列表中更新，短Toast通常可以退出；必须修正的提交错误，或唯一的下载入口，则不宜在用户来得及行动前消失。
有操作按钮的提示尤其需要保留足够的操作机会。Carbon建议带操作的Toast持续到用户关闭；实际产品也可以把关键操作放到稳定的页面或通知记录中。不要凭“行业都用3秒”统一安排所有消息，阅读长度、辅助技术和用户操作速度都不同。
“关闭”也要有明确含义。关闭横幅可能只是暂时收起提醒，并没有修好故障；已读消息不代表关联审批已经完成。通知中心应把消息阅读状态与业务处理状态区分开，避免用户点过通知就让待办自动消失。
如果一条提示在用户关闭后马上重现，用户会无法理解关闭按钮的作用。团队需要约定：本次会话内不再提示、状态变化后重新提示，还是该消息本来就不应提供关闭。决定应基于消息必要性，而不是统一套一个右上角叉号。
除了单条消息怎么显示，还应设计通知设置中的渠道、频率与免打扰，让用户区分即时提醒、汇总消息和必须送达的信息，并知道免打扰期间哪些通知会延后。
多条通知同时出现，按同一个事件归并
批量处理20条记录时，其中3条失败，不必为每条失败记录分别弹出Toast。可以提示“本次有3条记录未处理，请查看失败明细”，把逐项原因留在结果区域。这样既保留具体信息，也让用户知道总任务完成到什么程度。
归并时要区分同一次任务与不同任务。报表导出失败、资料保存失败和权限申请结果，不能为了减少数量合成一条“部分操作失败”，因为它们需要去不同地方处理。可以按任务标识、业务对象和事件类型去重，详细规则由实现确认。
旧通知也可能已经过时。例如“等待审批”之后到达“审批通过”，旧消息应能关联到当前状态；点击后不能打开一张仍显示待审批的旧快照。结果页面是事实入口，通知负责带路，重要状态需要在进入页面后重新确认。
让人一眼看懂对象、结果与动作
“操作成功”只在上下文非常明确时才足够。用户离开页面后收到消息，往往需要知道哪个对象发生了什么。“9月销售报表已生成”比“任务已完成”更能定位；“导出失败，请重试”如果缺少原因和数据是否保留，也不足以帮助行动。
- 同一对象沿用一致名称：页面叫“9月销售报表”，通知里不要换成用户不认识的内部任务编码。
- 动作写实际去向：用“查看失败明细”“打开导出记录”，减少含糊的“立即处理”。
- 警告说明后果：不要只写“请注意”，应指出哪些操作会受影响以及什么时候发生。
- 对普通用户隐藏不必要的技术细节，但可以提供支持排查所需的错误编号。
颜色与图标只能辅助表达。W3C对状态消息的说明强调，让辅助技术能够获知状态变化，不必为每条反馈强制移动焦点。原型交付时应写清消息是否需要被宣读、是否紧急以及焦点是否保持，由研发在实际界面中实现并验证。
把通知规范放回具体页面验证
使用墨刀原型时，可以用销售报表页、导出记录页和通知面板组成一段演示：创建9月报表导出任务，返回报表页，收到完成通知，再打开同一个任务。不要只做一页摆满消息组件的展示稿，因为那样看不出提示是否挡住操作，也看不出用户错过消息后能否找回结果。
评审可集中做三个动作：不看Toast直接继续工作，稍后寻找导出结果；连续创建多个不同任务，确认消息对象不混淆；关闭故障提醒后重新进入页面，确认故障状态仍得到正确表达。通知应在用户需要它时提供信息，也允许用户带着清楚的状态继续原来的工作。
如果还要统一按钮、输入框等控件的外观反馈，可继续阅读组件状态与变体的设计方法；页面遇到失败后的下一步，可参考后台异常状态的恢复路径。官方参考：Carbon Notifications、W3C Status Messages。
