1/4
Day 03 · Snackbar：有时候，反馈要带一个动作
Snackbar 是操作级反馈条，和 Toast 最关键的区别是：它可以带一个操作按钮（撤销、重试）。本期4张图讲清 Snackbar 的定义、与 Toast 的核心区别、3 种变体类型，以及最重要的使用判断标准：当用户可能后悔、需要一条退路时，选 Snackbar 而不是 Toast。
2026/6/12 · 9:12
ギャラリー
Toast 会在你做完事之后跳出来说「完成了」，然后自己消失。
Snackbar 也会这么做——但它有时候还会多问一句：要不要撤销？
这一个小小的区别，划出了两个组件的本质边界。参考来源：Material Design — Snackbar
图 1：Snackbar 是什么
Snackbar 是移动端（有时也在桌面端）底部出现的操作级反馈条，用来告知用户刚才的操作结果，并在需要时提供一次补救机会。
它和 Toast 最明显的外形区别：Snackbar 贴着屏幕底部，比 Toast 宽，通常横跨整个屏幕宽度或接近。
图 2：Snackbar vs Toast——3 个核心区别
两者都是轻量反馈，都会自动消失，都不应该强迫用户点击确认。区别在于三点：
位置：Snackbar 在屏幕底部，Toast 通常在屏幕中上部。
操作按钮：Snackbar 可以带一个文字按钮（「撤销」「重试」「查看」），Toast 没有——它只传递信息，不给选项。
消失方式：Toast 纯靠超时自动消失；Snackbar 可以超时消失，也可以让用户点操作按钮后主动关闭。
一句话总结：Toast = 告知结果；Snackbar = 告知 + 允许行动。
图 3：Snackbar 的 3 种类型
纯信息型：只告知结果，不带按钮。「操作已完成」。适合用户不需要做任何补救的场景。
单操作型：带一个文字按钮，最常见的是「撤销」。删除文件、发送消息、归档邮件——凡是能后悔的操作，都可以用它给用户一条退路。这是 Snackbar 最典型的使用形态。
双操作型：带两个按钮，例如「稍后」和「重试」。出现频率较低，因为两个选项会增加认知负担，只在网络断开等明确需要两种响应的场景使用。
图 4：使用要点
该用 Snackbar 的场景：
- 操作已完成，需要告知用户（删除、保存、发送）
- 提供一次性撤销机会（撤销删除、撤回发送）
- 后台任务状态更新（上传中、同步完成）
- 不打断用户当前操作流程时
不该用 Snackbar 的场景：
- 需要用户确认的重要操作——该用 Dialog
- 错误信息需要详细说明——该用 Alert 或 Banner，因为 Snackbar 会自动消失，用户来不及读完
- 同时出现多条通知——Snackbar 一次只显示一条，多条排队会让用户困惑
- 信息需要长时间停留供用户阅读——Snackbar 超时即消，不适合承载复杂内容
下期预告：Badge——那个小红点，什么时候该出现，什么时候该消失。
コメント