李创奇去年年底我把一个 Flutter 项目的提示层全部重构了一遍，起因是在 OpenHarmony 的 RK3568 板卡上，产品反馈“删除文件后没有任何反馈”。我第一反应是查代码，结果代码里确实调用了 showSnackBar，SnackBarAction 的撤销按钮也写了，但屏幕就是干干净净。后来排查了几个小时，问题不在组件本身，而在 ScaffoldMessenger 的调度机制上。也是从那次开始，我意识到 SnackBar 这类轻提示，背后牵扯的状态和层级问题一点都不比复杂弹窗少。
这篇文章把我的实测结论、踩坑过程和一份可以直接参照的提示规范整理出来，给做 Flutter 应用、尤其是要在 OpenHarmony 设备上跑 Flutter 的团队参考。无论你是刚接触 SnackBar，还是已经在项目里用了很久但总觉得哪里不对，应该都能找到对应的问题。
1. 提示组件的边界：SnackBar 在 Flutter + OpenHarmony 场景中的真实定位
很多 Flutter 开发者拿到需求第一反应是“弹个提示”，但提示和提示之间差别很大。有人把 SnackBar 当 Toast 用，有人把所有操作确认都塞进 Dialog，还有人干脆做一个全局 Overlay 来显示所有提示。这些做法都能跑，但维护起来就是另一回事了。
Flutter 官方内置的提示组件其实分工很明确：
| 提示类型 | 交互强度 | 典型场景 | Flutter 实现 | OpenHarmony ArkUI 对应 |
|---|---|---|---|---|
| SnackBar | 低-中 | 操作结果反馈、撤销入口 | SnackBar + ScaffoldMessenger | promptAction.showToast / 自定义弹层 |
| Toast | 极低 | 纯通知，无需处理 | 第三方包或 Overlay 实现 | promptAction.showToast |
| Dialog | 高 | 必须确认、用户决策 | AlertDialog / showDialog | promptAction.showDialog / 自定义弹窗 |
| BottomSheet | 中 | 补充操作、多选项 | showModalBottomSheet | bindSheet / 半模态 |
SnackBar 的定位是“结果式反馈”：用户完成了某个操作，告诉用户结果是什么，最多给一个反悔或补救入口。它不需要用户停下来做决策，不会阻塞当前操作流，到时间就自动消失。这是它和 Dialog 最本质的区别——Dialog 是打断式的，SnackBar 是伴随式的。
我记得有个需求是“分享成功之后弹一个二维码，让用户确认是否查看详情”，如果当时用 SnackBar 承载二维码，体验会非常奇怪：SnackBar 会自动消失，用户根本来不及扫码。这种场景应该用 Dialog 或单独页面。反过来，如果只是“删除成功”这种反馈，用 Dialog 就太重了，还要用户点一个“确定”才能继续，纯属多余。
在 OpenHarmony 上做 Flutter 应用，还有一层额外的选择：是用 Flutter 的 SnackBar，还是让原生侧弹一个 ArkUI 的 promptAction？我的建议是：只要提示发生在 Flutter 渲染的页面里，一律用 Flutter 的 SnackBar。原因很简单——ArkUI 的原生提示无法感知 Flutter 页面的布局、深色模式、字体缩放，混用会出现提示风格不一致、位置漂移、颜色对不上的情况。用户不会关心这个提示是哪个框架弹的，他只看体验是否统一。
另外，做提示规范的第一条其实是“砍提示”。很多产品经理的习惯是把每个操作都加个提示，好像没有反馈用户就不知道发生了什么。但实际上，像“点击按钮跳转页面”这种操作，页面切换本身就是反馈；像“滑动删除列表项”这种操作，列表项消失就是反馈。SnackBar 要留给真正需要补充信息、或者需要提供撤销入口的操作。一条 SnackBar 如果连文案都说不清要解决什么问题，那它就不该存在。
理解了这个边界，我们再看 Flutter 内部真正驱动 SnackBar 显示逻辑的 ScaffoldMessenger。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. ScaffoldMessenger 调度机制：SnackBar 显示、排队与销毁的核心原理
2.1 从 Scaffold.of 到 ScaffoldMessenger：为什么必须换新 API
很多老项目里还能看到这种写法：
dart复制// 老代码：不推荐
Scaffold.of(context).showSnackBar(
SnackBar(content: Text('已保存')),
);
这个 API 本身没问题，但有两个致命的坑。第一，Scaffold.of(context) 要求传入的 context 必须在某个 Scaffold 的子树里，否则运行时会直接抛异常。很多团队把这段代码抽到一个公共方法里，调用处的 context 离 Scaffold 很远，一跑就崩。第二，路由切换之后，旧的 context 对应的 Scaffold 状态可能已经不在了，但 SnackBar 还傻乎乎地想要弹出来，表现就是“代码执行了，页面没反应”。
Flutter 官方后来把 SnackBar 的调度权从 Scaffold 提升到了 ScaffoldMessenger，目的就是把“显示提示”和“Scaffold 布局”解耦。ScaffoldMessenger 的状态放在 MaterialApp 这一层，不依赖某个具体页面的 Scaffold 状态，所以在任何地方都能安全地弹提示。
2.2 三层结构：调度中心、展示容器、数据载体
可以这么理解这三层的关系：ScaffoldMessenger 是调度中心，负责决定 SnackBar 什么时候显示、显示在哪、要不要排队；Scaffold 是展示容器，负责把 SnackBar 挂在页面底部；SnackBar 本身只是数据载体，里面装了内容、操作按钮、持续时长这些信息。
我用一个比较容易理解的方式类比：ScaffoldMessenger 相当于餐厅前台，`Scaff