服务端如何发送仅在应用内展示的通知（非推送通知）

核心约束匹配：通知仅在应用打开状态下于应用内展示，不触发系统通知栏、锁屏弹窗；应用未运行时无需维持长连接、不做系统级唤醒。

方案选型逻辑 #

传统WebSocket方案因为应用退后台/被杀进程后连接必然断流，需要服务端持续维护连接状态、做异常重连处理，运维成本和场景需求完全不匹配——毕竟你的目标场景是用户参与答题竞赛，结算时用户本来就大概率在应用前台等待结果，完全不需要为了离线场景做重投入。

具体服务端落地配置 #

1. 在线状态校验逻辑搭建 #

• 服务端维护轻量的用户在线状态表，记录每个用户的最后一次心跳上报时间戳、当前活跃会话ID：只要用户距离最后一次心跳的间隔小于30s，就判定为应用处于前台打开状态
• 竞赛结算完成生成获胜通知时，服务端逐一对获胜用户做状态校验：
  • 若用户处于在线状态：直接通过轻量的SSE通道（比WebSocket服务端维护成本低，不需要双向通信）把通知内容下发到客户端，通知结构包含庆祝图标静态资源地址、卡片文案、答题结果页跳转参数
  • 若用户处于离线状态：直接把通知条目存入用户的离线消息库，不触发任何系统级推送动作，等待用户下次打开应用时再拉取展示

2. 应用打开时的拉取兜底逻辑 #

• 新增固定API接口/api/notification/pending-list，客户端在两个固定时机主动调用拉取：
  1. 应用完成启动鉴权、首屏加载阶段
  2. 应用从后台切回前台的瞬间
• 服务端对该接口的返回规则：仅返回带in_app_only标签、未被客户端上报已读的通知条目，直接返回前端可直接渲染的卡片配置（含庆祝图标路径、标题、跳转参数）

3. 系统通知隔离的硬规则配置 #

从根源上杜绝系统通知栏、锁屏弹窗的误触发：

• 所有这类应用内通知在服务端存储时，强制打上display_scope = in_app_only的元标签
• 服务端消息路由层做硬拦截：只要消息携带in_app_only标签，就完全不允许路由到厂商推送网关、FCM等会触发系统通知的通道，哪怕后续你接入其他类型的系统推送能力，也不会影响这类内通知的展示逻辑
• 通知条目生成全局唯一ID，客户端收到展示后需调用已读上报接口，服务端收到上报后就将该条通知标记为已处理，避免重复拉取造成的卡片重复弹出

答题竞赛场景的轻量化适配 #

针对你提到的答题获胜通知场景，服务端可以做流程简化，不需要搭建通用通知中台：

• 竞赛结算完成后，批量把获胜用户的通知条目写入存储表，直接关联预置好的带庆祝图标的通知卡片模板ID
• 拉取接口做优先级排序：竞赛结束后2小时的时间窗口内，获胜用户的通知条目排在拉取列表最前面，客户端打开应用后第一时间渲染展示即可，完全不需要为应用未运行的场景做任何连接维护、消息推送动作

内容的提问来源于stack exchange，提问作者Bhanwarlal Chaudhary