Toast和Snackbar通知系统

Toast和Snackbar通知系统 是做什么的？

目的

Toast和Snackbar通知系统提供了一套用于设计临时、非阻塞通知层的方法论。这些是短暂、可自动关闭或手动关闭的UI组件，位于主界面上方的专用层级中。与模态弹窗不同，它们不会抢占焦点或中断用户流程；相反，它们作为一个被动的、高可见性的“确认回路”，告知用户一个后台或即时任务已成功、失败或需要注意。本系统确保Toast视觉统一、位置避免遮挡关键控件，并且对鼠标、触摸和辅助技术用户完全无障碍。

使用场景

• 异步操作： 确认文件已上传、草稿已保存或记录已在后台删除。
• 微提交确认： 确认如将商品加入购物车、复制链接到剪贴板或切换局部系统偏好等操作。
• 可逆的破坏性操作： 通知用户某个项目已被归档或删除，并在Snackbar中提供“撤销”操作。
• 临时状态更新： 显示短暂的自动系统提示，例如切换到“离线”或“在线”状态。

何时不使用

• 高重要性系统阻塞： 如果严重错误需要立即干预或阻止用户继续操作（例如会话过期、支付失败）；请使用 overlay-and-dialog-system (模态弹窗)。
• 持久性区域警告： 如果警告或错误与整个区域、页面或表单上下文相关，并且需要保持可见直到解决；请使用 banner-and-alert-system (内联提示)。
• 表单验证消息： 如果用户在特定输入字段中出错；请使用 form-design-system (字段级验证)。
• 主要内容发现： 切勿使用Toast呈现主要内容、营销公告或导航选项。

输入

1. 消息严重程度/类型： 成功（确认）、信息（中性更新）、警告（非阻塞问题）或错误（操作失败）。
2. 操作要求： 反馈是被动的（只读），还是包含一个单一微操作（例如“撤销”、“查看”、“重试”）？
3. 屏幕空间和设备类型： 目标视口（桌面、平板、手机）以及主要输入方式（鼠标悬停 vs 拇指可达区域）。
4. Z索引和分层策略： 堆叠上下文规则，防止与顶部导航、固定页脚或活动覆盖层重叠。

输出

1. 组件解剖规范： 基于网格的容器、图标槽、消息字符串、操作CTA和关闭按钮蓝图。
2. 空间对齐和放置规则： 针对桌面端（例如右上或右下堆叠）和移动端（例如底部全宽滑入）的自适应坐标。
3. 排队和堆叠逻辑： 处理同时出现提示、最大可见数量和过期排序的系统规则。
4. 交互式时间线和过期规范： 管理自动关闭超时、悬停暂停行为和滑动手势的规则。
5. 无障碍/ARIA蓝图： 实时区域的语义映射、交互式Toast的焦点处理以及屏幕阅读器公告。

工作流程

1. 结构组件解剖

使用标准间距令牌定义Toast容器的精确间距和布局网格：

• 图标槽： 固定宽度（例如20px或24px），位于最左侧。使用语义化、高对比度的状态图标（成功用勾选标记，警告/错误用感叹号三角形，信息用信息圆圈）。
• 文本区域： 左对齐、自动换行的排版，包含简短的标题（加粗，可选）和描述。切勿用省略号截断文本；最多允许换行至3行。
• 操作槽（可选）： 位于消息右侧的单个、高度可见的文本按钮（例如“撤销”）。对于移动端的长文本，将操作换行到新行并右对齐。
• 关闭触发器： 位于最右侧的清晰“X”关闭按钮。必须拥有至少24x24px的点击区域（触控目标首选44x44px）。

2. 根据视口确定空间放置

• 桌面端放置： 将Toast容器堆叠放置在屏幕的右上角或右下角。保持与视口边缘一致的24px偏移量。
  • 右上堆叠： 当主要操作流程发生在页面下部区域时最佳。
  • 右下堆叠： 当顶部导航或实用栏占用上边距、需要防止重叠时最佳。
• 移动端放置： 将桌面端堆叠转换为底部固定、全宽的Snackbar（距左、右、下边缘12px至16px外边距）。这使交互保持在最佳的“拇指可达区域”内。
• Z索引规则： 始终分配专用的z-index令牌（例如z-index: 5000或更高），使其位于标准粘性标题（z-index: 1000）之上，但位于活动全屏覆盖层（z-index: 10000）之下。

3. 建立堆叠和排队逻辑

管理高触发频率环境而不引起布局抖动或认知过载：

• 最大可见限制： 将活动队列限制为最多3个可见Toast，垂直堆叠。
• 堆叠方向：
  • 如果放置在屏幕顶部，新Toast从顶部滑入，将旧Toast向下推。
  • 如果放置在屏幕底部，新Toast从底部滑入，将旧Toast向上推。
• 排队缓冲： 如果在3个Toast活跃时触发了第4个，将新Toast缓冲在内存中。当最旧的可见Toast自然过期淡出后，立即渲染它。

4. 编写过期和悬停暂停时间线

Toast必须存在足够长的时间以便阅读，但同时迅速消失以清理屏幕：

• 动态生存时间（TTL）： 根据内容长度计算过期时间：
  • 简短被动Toast（< 40个字符）： 5秒后关闭。
  • 较长或包含操作的Toast： 7至10秒后关闭，以确保屏幕阅读器能完整播报，用户也有时间阅读和操作。
  • 错误/失败Toast： 不自动关闭。保持可见，直到用户手动点击“X”按钮，确保关键反馈不会丢失。
• “悬停暂停”交互：
  • 如果鼠标用户悬停在Toast队列的任何部分上，冻结所有活动TTL倒计时。仅在鼠标离开Toast边界后重置并恢复计时器。
  • 如果键盘用户聚焦到Toast内的任何元素，则无限期冻结计时器。仅在焦点移回主文档时恢复倒计时。

5. 定义关闭和手势行为

• 触摸滑动： 在移动设备上，允许用户通过水平向左或向右滑动将单个Snackbar立即滑出屏幕。拖动阈值保持为视口宽度的30%。
• 动画： 使用平滑的、硬件加速的过渡效果（例如transform和opacity），入场动画持续200ms至300ms并使用cubic-bezier(0.16, 1, 0.3, 1)（缓出指数函数），退出动画使用简单的opacity淡出。

---

决策规则

堆叠对齐矩阵

视口	主要导航布局	推荐的Toast放置位置	动画方向
桌面	左侧边栏/仪表板	右下角（保持主要工作区清晰）	从屏幕外向左滑入
桌面	固定顶部标题	右下角（防止遮挡导航）	向左或向上滑入
桌面	极简/底部内容丰富	右上角	向左或向下滑入
移动端	任意	底部居中/全宽	从底部边缘向上滑入

过期逻辑矩阵

Toast严重程度/类型	包含操作按钮？	推荐过期时间	关闭类型
成功/信息	否	5秒（固定）	自动关闭 + 手动关闭
成功/信息	是（“撤销”/“查看”）	8-10秒	自动关闭 + 手动关闭
警告	否	7秒	自动关闭 + 手动关闭
错误/失败	是或否	无限（保持持久）	仅手动关闭

---

约束

• 无障碍性（WCAG 2.2 合规）：
  • ARIA实时区域： 将被动Toast映射到role="status"（默认aria-live="polite"和aria-atomic="true"）。除非是传达系统失败（例如“互联网连接丢失”），否则避免使用role="alert"（断言性），因为断言性警报会立即中断屏幕阅读器的朗读。
  • 键盘导航（WCAG 2.2 SC 2.1.1）： 当Toast包含交互操作（例如“撤销”或“查看”）时，它必须可通过键盘访问。由于键盘Tab循环可能较慢，请提供一个全局快捷键（例如Escape关闭当前活动Toast，或F6将焦点直接移到Toast队列容器），或者将Toast容器紧跟在DOM Tab顺序中的触发元素之后。
  • 无焦点陷阱： 切勿将键盘焦点困在Toast队列内。用户必须能够自由Tab出Toast回到页面内容。
• 对比度（WCAG 2.2 SC 1.4.3）：
  • 所有文本、状态图标和按钮与Toast背景的对比度必须达到最低要求：
    • 普通文本：4.5:1 最低对比度。
    • 图标和活动控件边框：3:1 最低对比度。
• 响应式设计：
  • 在视口宽度 < 600px 时，Toast容器必须跨满全宽（width: calc(100% - 32px)），并居中对齐，以防止出现尴尬的边距列。

---

常见失败模式

• “遮挡操作”陷阱： 将桌面Toast队列直接放置在高频交互元素上方，例如购物车标题按钮或表格过滤下拉菜单，导致用户误点击。
• “现在看到，现在消失”闪烁： 在2-3秒内自动关闭复杂的多词错误或警告。这违反了基本的无障碍阅读阈值，并让错过上下文的用户感到困惑。
• 屏幕阅读器静默： 在没有ARIA实时区域包装器的情况下动态将Toast添加到DOM，使其对视觉障碍用户完全不可见。
• 布局抖动： Toast进入时队列高度突然变化，导致主页面内容上下跳动。
• 忽略悬停/焦点过期： 当用户正在悬停阅读密集文本消息或悬停在“撤销”CTA上时，让Toast自行关闭，导致他们点击“空区域”并触发意外操作。

---

验证标准

• Toast使用不同的、高对比度的语义指示符（颜色+唯一图标）进行样式化。
• 在桌面上，Toast不与主要导航元素或全局操作区域重叠。
• 在移动端，Toast转换为底部固定、全宽的组件，拇指易于触及。
• 鼠标悬停或键盘聚焦时，活动计时器立即暂停。
• 包含操作的Toast至少保持可见8-10秒；错误Toast永不自动关闭。
• 正确指定语义化的屏幕阅读器标记（role="status"或role="alert"）。
• 键盘用户可以导航到并触发Toast操作按钮，而无焦点陷阱障碍。
• 所有交互元素（关闭按钮、CTA）满足WCAG 2.2 24x24px最小触控目标（首选44x44px）。