连续吐司需要排队而非覆盖
别名: 吐司队列 · snackbar queue · 提示覆盖
概念解释
排队（queueing）指多条吐司在短时间接连触发时，后一条等前一条完成自己的可见周期再登场，而不是在同一位置把前一条像素替换掉。覆盖会让用户只看到最后那一帧。保存成功随即被网络错误盖住，人可能以为保存失败；反过来，错误被后到的「已复制」盖住，失败就被默默取消了。排队保护的是每条消息作为一次独立事件被看见的机会，不管单条该停留多久、是不是必读。
机制
同一屏幕坐标上的物体被瞬间换成另一个，视觉系统拿到的是后一个物体，前一个的身份没有被当成「消失了的对象」保存下来。吐司又没有列表或日志可回看，被覆盖等于物理删除。连续触发在真实产品里很常见：一次操作会连发「已保存」和「已同步」，批量操作会为每一项各发一条。覆盖把多事件压成单事件，用户用最后一条的语气概括整段过程。排队恢复了时间上的可分节，但队列过长会把反馈拖成表演，后面的消息到达时，它要解释的那个动作已经不在工作记忆里。所以排队的对象是短突发，不是无限堆积。
怎么研究
在一次用户动作之后连续发出两条或三条含义不同的吐司，比较覆盖与排队两种调度。
自变量：两条消息的间隔、是否关于同一对象、后一条是否语义上取代前一条（如「保存中」被「已保存」取代）、队列最大长度。 因变量：两条内容能否都被报告、报告顺序是否正确、是否用后一条的效价评价前一个动作。
关键对照是「后一条否定前一条」与「后一条补充前一条」。前者覆盖可能是对的，后者覆盖会造成系统性误判。实验后要追问的不是「你看见提示了吗」，而是「保存成功了吗、复制成功了吗」两件事实。
边界
同一对象的状态更新应当合并，而不是排队：进度从 30% 到 70% 不应变成两条吐司。后一条明确取代前一条时（「保存中」→「已保存」、「发送失败」→「已重试成功」），替换是正确的调度，排队反而会让过期状态多活一轮。五条以上还在排队，说明反馈粒度错了，应改成一条摘要（「12 项已保存，2 项失败」）或把明细放到操作对象旁边。全屏通知权限下，系统级提示可能不走应用内队列，应用内再排一次会双份打扰。
怎么落地
- 为吐司建一条有上限的队列；默认先进先出，只有后一条被标成同一对象的状态更新时才允许替换。
- 批量操作不要为每一项弹一条，改成结束时的一条汇总，把失败项留在列表里。
- 给队列设硬顶（例如三条），超出的合并为「还有 n 条通知」，避免把界面变成走马灯。
- 验证：在一次保存里故意再触发复制或同步失败，问用户两件事各自的结局。只能说出最后一条，就是覆盖在删信息。