APNS图标徽章计数实现：聚合2个tabItem角标方案咨询

核心结论：必须后端维护用户维度的角标计数 #

不存在纯客户端实现、或依赖推送服务原生能力就能保证角标准确的方案，原因很明确：

• iOS 系统更新应用角标是直接读取 APNS 推送载荷里的 badge 字段，全程不需要唤醒 App。如果 App 被用户杀进程、或者设备断网期间推送堆积，客户端根本接收不到推送触发的回调事件，完全没机会自行计算更新角标值，纯客户端计数必然出现偏差。
• 包括 Azure Notification Hubs 在内的通用推送服务，只负责按标签、设备Token完成推送路由，本身不存储任何业务维度的未读状态，不可能原生提供角标计数计算能力。
• 市面上聊天、资讯类带角标的成熟应用，全部采用后端维护计数的方案，没有例外。

关于Azure Notification Hubs适配的存储要求 #

你判断的最低存储粒度是对的：不需要一开始就做单条通知送达状态的细粒度存储，按「用户ID + 通知类型」维度存储计数记录就可以满足需求，你构思的「仅为已授权开启对应通知类型的用户维护记录」的思路也完全合理，能避免大量无效数据存储。
需要注意你当前用Tags做群组批量推送的逻辑有个坑：群组标签推送的载荷是全局统一的，没法给不同用户填充不同的badge值，直接用标签批量推会导致所有用户收到的角标数完全一致，数据必然错误。正确的推送流程应该调整为：

• 产生新通知时，先查询出目标群组下所有开启了对应通知权限的用户列表
• 通过原子操作（Redis INCR、数据库行级锁更新），对每个用户对应通知类型的计数做+1，同时聚合两个Tab的计数得到该用户的总角标值
• 为每个用户单独组装带专属badge值的推送载荷，再通过ANH下发，不要直接用群组标签发统一载荷

其他落地注意事项 #

• 你写的示例推送结构有合规问题：aps 是APNS规定的系统保留字段，自定义的业务字段（比如你加的alert type）不能放在aps节点下，要放在和aps平级的根目录，否则可能被APNS解析拦截。正确的载荷格式参考：

{
     "aps": {
          "alert": "Test notification",
          "badge": 9
     },
     "alert_type": "inbox"
}

• 计数更新一定要用原子操作，禁止先查值、再修改、再写回的非原子逻辑，避免并发推送时出现计数覆盖、数值不准的问题。
• 角标重置逻辑要做双向对齐：用户点击进入对应Tab阅读内容后，客户端除了本地清除角标，必须同步上报已读事件给后端，后端将对应类型的计数清零/扣减对应值，保证后续推送携带的角标值正确。
• 如果存在同一账号多台iOS设备登录的场景，计数要按用户维度维护，不要按设备维度单独存，否则多设备切换时会出现角标数值不一致的问题。

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