用户登出时如何处理自定义topic的推送通知？

1. 客户端登出流程绑定退订逻辑 #

• 在用户主动登出、token过期自动登出的代码逻辑中，新增退订前置步骤：遍历当前登录用户所有未完成的订单topic，调用推送服务商的批量退订接口完成退订后，再执行本地登录态清理、缓存清除操作。
• 针对极端情况（比如用户直接卸载APP未走登出流程），可以在APP每次冷启动时校验登录态，若检测到当前无有效登录态，先触发一次全量历史订单topic退订，再走后续业务流程。

2. 服务端推送层新增校验兜底 #

• 所有订单状态变更推送下发前，新增两层校验：首先校验目标订单关联的用户当前是否处于有效登录态，其次校验要推送的设备标识是否和该用户当前绑定的设备一致，只有两项校验都通过才实际下发推送。
• 你可以将用户-设备绑定关系、用户登录态存储在Redis中，单条校验耗时在1ms以内，不会影响订单推送的实时性。

3. 订阅架构优化（可选） #

如果当前推送服务商支持标签能力，可以替换原来的按订单ID订阅topic的逻辑：

• 用户下单后，给当前用户绑定的设备打上order_{订单ID}的标签，推送时直接给对应标签的设备发通知即可。
• 用户登出时直接清空该设备的所有订单类标签，不需要遍历退订N个topic，维护成本更低。

4. 离线订阅清理机制 #

• 每日定时跑批任务，统一清理已完成/已取消订单的topic订阅关系、以及对应用户已登出超过48小时的无效订阅，避免无效订阅占用推送服务商的配额，也能从根源减少误发概率。

内容的提问来源于stack exchange，提问作者Omar Abdelazeem