吐司自动消失，不适合承载必读信息
别名: Snackbar · 轻提示 · 自动消失提示 · transient toast
概念解释
吐司（toast）是一条不抢焦点、通常贴在屏幕边缘的短暂状态消息，系统会在一段时间后自行收起。它和横幅、对话框的差别不在文案语气，而在谁决定阅读结束：吐司由计时器关闭，读者没有被要求确认「我看过了」。因此它只适合承载错过也不改变下一步的信息——「已保存」「已复制」「已加入收藏」。密码、权限变化、不可撤销的失败、必须立刻处理的校验，都不是吐司该说的话。把必读内容放进吐司，等于把关键事实交给一场和注意力的赛跑。
机制
人正在做主任务时，边缘出现的短消息首先落在周边视觉里。要读懂它，需要一次注视转移；若转移发生在消息消失之后，内容就没有进入工作记忆。吐司还不占布局里的稳定位置，消失后没有可回看的锚点，回忆只能靠刚才那一次扫视。必读信息的判定标准是：漏看会不会让下一步动作选错。复制成功漏看，用户顶多重贴一次；提交失败漏看，用户会以为已经成功并离开。自动消失把「系统认为这件事已经交代过了」和「用户实际读到了」拆成两件事，后者经常完不成。
怎么研究
用双任务测量吐司的漏检：主任务是填写表单或浏览列表，次任务是事后报告刚才出现过的消息内容与含义。
自变量：消息是否要求后续动作、出现时用户是否正在键入、吐司位置（顶部 / 底部 / 靠近操作点）、主任务的视觉负荷。 因变量：检出率、内容回忆、是否做出与消息相反的下一步（例如失败后仍关闭页面）。
实验室里被试知道「会有提示」，检出率会被抬高。更接近产品的做法是把吐司嵌进真实提交流程，事后问「刚才保存成功了吗」，而不是问「你看见提示了吗」。看见和读懂不是同一件事。
边界
若同一结果在界面上另有持久证据——列表里多了一行、按钮文案变成「已保存」、输入框旁留下标记——吐司只是重复确认，漏看代价低。撤销类吐司看起来像必读，但若历史记录或回收站仍能补救，它仍可以是短暂的；只有撤销入口只活在吐司上时，它才升格为必读，也就不再适合自动消失。全屏朗读或放大显示时，用户可能还没扫到边缘消息计时就已经结束。会议投屏、第二显示器上的操作，吐司还可能出现在用户没在看的那块屏幕上。
怎么落地
- 按「漏看是否改变下一步」给每条消息分级：确认类用吐司，必读类改到字段旁、页内横幅或需要响应的对话框。
- 禁止用吐司展示无法在别处再找到的信息：一次性验证码、完整错误原因、权限被收回。
- 提交失败、支付未完成、冲突覆盖这类结局，反馈要留在操作对象旁边，直到用户处理或明确关闭。
- 验证：关掉吐司通道做一遍主流程。若关掉之后用户会做出错误的下一步，这条消息就不该走吐司。