同一Apple ID下多设备APNS Token重复，如何实现推送至新设备？

这个问题我之前帮团队排查过类似的情况，核心要从Token的上报管理和推送逻辑优化两个层面入手，下面给你一步步拆解解决方案：

1. 先搞清楚为什么会出现相同Token？ #

正常来说，APNS Token是绑定「设备+应用+Apple推送环境（开发/生产）」的唯一标识，不同设备应该返回不同的Token。但如果用户是通过iCloud备份恢复应用到新设备，或者应用端没有正确处理Token更新，就可能出现同一Apple ID下两台设备上报相同Token的情况——旧设备的Token其实已经失效，但你的服务器还在沿用它。

2. 应用端必须做好Token的实时上报与设备关联 #

这是解决问题的基础：

• 每次应用启动、或者收到didRegisterForRemoteNotificationsWithDeviceToken回调时，强制上报最新的Token到服务器，不要只在首次安装时上报一次。
• 上报时，除了Token和用户ID，还要带上设备的唯一标识（比如用identifierForVendor，或者自己生成一个UUID存在钥匙串里，确保卸载重装也能保留），以及上报时间戳。这样服务器能区分每个Token对应的设备，以及哪个是最新的。

3. 服务器端优化推送逻辑 #

• 不要给用户只存一个Token，而是维护一个「用户ID -> 多个Token（含设备标识、上报时间）」的映射列表。
• 推送时，优先选择最近上报的Token（也就是新设备的），或者直接只给最后一次上报的Token发送。如果担心漏发，可以先给新Token发送，若收到APNS的无效响应，再尝试旧Token（不过这种情况很少见）。
• 利用APNS的反馈机制：当发送到某个Token收到Unregistered错误时，立即从数据库中移除这个Token，避免后续再推送到无效设备。

4. 额外的优化建议 #

• 在应用端新增「设备标记」功能：用户在新设备登录时，自动标记该设备为「当前活跃设备」，服务器推送时优先选择这个标记的Token。
• 定期清理过期Token：比如超过30天没有上报心跳（或Token更新）的设备，标记为无效，不再推送。

按照这些步骤调整后，应该就能确保推送到用户的最新设备了。如果还有问题，可以检查下应用端是否在Token更新时遗漏了上报，或者服务器的Token存储逻辑有没有覆盖最新数据的情况。

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