同类通知需合并为摘要
别名: 通知合并 · 摘要聚合 · notification grouping
概念解释
多条同类到达时，通知栏应收成一条摘要，而不是每人、每赞、每条物流节点各占一格。「同类」指同一会话、同一对象上的同一事件类型，或短窗口内可被同一意图处理的重复状态。摘要的工作是减少栏内卡片数，让一次扫视覆盖一组变化。
这条是呈现层的合并：已经到达的条目如何收起来。它不是把待发送的推送攒到同一个时刻再发出，也不是专注模式结束后给一份「刚才挡了什么」的清单。
机制
通知栏的扫视容量很小。每张卡片都要抢标题行，重复卡片把真正不同的事件挤出视口。人处理重复事件的单位本来就是集合：「这串聊天有新消息」，而不是「第三条、第四条」。拆开呈现强迫人做集合运算。合并把运算交给系统，用户看到的是已经分好组的对象。
合并键必须稳定。按「刚刚」这种滑动时间窗乱并，会出现把无关来源捆在一起、或把同一会话拆成两堆。键通常是线程 ID、对象 ID 加事件类型。跨类型硬并（把付款失败和好友赞捆成「3 条更新」）会毁掉下一步动作，因为集合里没有单一意图。
怎么研究
给同一组到达事件，比较「一条一张」与「按线程摘要」，在有限时间扫视后问：有几个需要处理的对象、哪个最急。
自变量：合并键（线程 / 应用 / 时间窗）、摘要是否露出最新一条正文、栏内可见卡片上限。 因变量：对象识别正确率、漏掉的高后果条目、清除全部所需手势数、扫视时间。
实验室里条目少、时间充裕，合并的优势会被低估。把栏填满到必须滚动，差异才出现。不要用「觉得更干净」当终点——干净但说不清是谁的消息，合并就失败了。
边界
每条都必须单独决策的告警（不同设备的故障、不同订单的取消）不能并成一条「3 条异常」，否则人会按一条去处理。实时协作里「正在输入」这类瞬态不应并进持久摘要。只有一条时硬出「1 条新消息」比直接出正文更差。无障碍展开若只读摘要数字不读成员，合并会把细节藏死，展开必须可被辅助技术遍历。
怎么落地
- 按会话或对象+类型合并；跨应用、跨类型不要并。
- 摘要标题写对象和条数，默认露出最新一条可辨认的正文，而不是只有数字。
- 新到达应并进已有卡片，而不是在栏顶再插一张同类。
- 验证：在五分钟内向同一会话推十条、向另一对象推一条高后果。扫视栏的人应报出「一个会话在更新、另有一条单独的」，而不是十一张平铺。报不出那个单独对象，合并键就错了。