通知收件箱分诊模型

大理论

一个成熟产品通常同时有 toast、inline message、banner、modal、badge、notification panel 和 notification center。它们承担不同注意力成本。若所有事件都进入同一种 toast 或同一个红点，用户会疲劳、忽略关键风险，或者找不到稍后处理的任务。通知收件箱的设计重点是分诊：把消息按需要行动、信息更新、失败/风险、系统维护、协作提及和已归档状态组织起来。

小知识点

1. 先定义事件等级：blocking、action required、warning、info、success、ambient update；不要让所有事件都使用红点。
2. Badge 只适合给已有入口补充数量或状态；重要内容本身要在页面或收件箱可见。
3. 每条通知至少包含来源对象、事件、时间、状态、可执行动作和返回路径，例如项目、评论、审批、账单或安全设置。
4. read/unread、seen/unseen、archived/dismissed、snoozed、failed/retry 是不同状态，不能合并成一个已读布尔值。
5. 批量标记已读、归档、静音和过滤应只对当前筛选范围生效，并显示数量与撤销路径。
6. 可访问通知要谨慎使用 live region；不是所有状态变化都应该用 aggressive alert 打断读屏用户。

设计判断

如果用户能快速判断哪些通知需要现在处理、哪些只是记录、每条来自哪里、处理后状态如何变化，通知系统是健康的；如果红点只让用户焦虑却没有分诊路径，它就是噪音。

实现建议

建立 notification schema：id、sourceType、sourceId、actor、verb、object、severity、attentionLevel、createdAt、readAt、seenAt、archivedAt、snoozedUntil、primaryAction、secondaryAction、deepLink、deliveryChannel、dedupeKey。前端区分 toast/inline/banner/inbox；收件箱提供 tabs 或 filters、批量操作、空状态、失败重试和偏好设置。移动端不要只显示红点，至少保留数量、最新摘要和进入路径。

反例/风险

所有成功消息都进入通知中心、删除类风险只用 toast、一条事件重复出现多次、badge 数量没有解释、归档等于删除、批量已读没有 undo、通知只支持 hover 展示详情、屏幕阅读器被频繁 alert 打断。

案例分析

Carbon 的 notification pattern 区分 inline、toast、actionable、modal、banner、notification panel 和 notification center 等不同场景；Material 3 Badges 把 badge 定义为导航项或图标上的通知、数量和状态；Atlassian 的 section message/flag 用于特定区域或轻量确认；GOV.UK notification banner 明确不应用来替代表单错误摘要。可学习点是：通知类型要按注意力成本和任务范围选择，收件箱只是其中一种持久分诊模式。

来源链接

Carbon notification pattern: https://carbondesignsystem.com/patterns/notification-pattern/ Carbon notification usage: https://carbondesignsystem.com/components/notification/usage/ Material 3 badges: https://m3.material.io/components/badges Atlassian designing messages: https://atlassian.design/foundations/content/designing-messages GOV.UK notification banner: https://design-system.service.gov.uk/components/notification-banner/