FCM（Firebase Notifications）同一应用多APNS令牌冲突问题求助

我前段时间刚好碰到过和你一模一样的场景——iOS里常规推送和Location Push的APNS令牌冲突，FCM的setAPNSToken每次都会覆盖之前的令牌，导致后端用同一个FCM令牌发不同类型推送时总是出错。结合官方文档和实际踩坑经验，给你几个可行的解决方案：

方案一：后端直接维护不同类型的APNS令牌，绕过FCM转发 #

这个是我最终采用的方案，操作起来最直接：

• 客户端同时获取常规APNS令牌（从didRegisterForRemoteNotificationsWithDeviceToken拿到）和Location Push专用令牌（调用startMonitoringLocationPushes返回的），把这两个令牌连同当前的FCM令牌一起上传到你的后端。
• 后端为每个设备/用户建立一个映射表，比如：

  {
    "fcm_token": "你的FCM令牌",
    "regular_apns_token": "常规推送的APNS令牌",
    "location_apns_token": "Location Push的APNS令牌"
  }
  

• 当需要发送推送时，根据类型选择对应的APNS令牌直接调用APNS接口发送，而不是通过FCM中转。这样完全避开了FCM令牌只能绑定一个APNS令牌的限制。

方案二：使用多个Firebase项目隔离不同推送类型 #

如果你们团队依赖FCM的其他功能（比如消息统计、多平台兼容）不想放弃FCM中转，可以考虑创建两个Firebase项目：

• 一个项目专门处理常规推送，客户端初始化这个项目的FCM实例后，调用setAPNSToken绑定常规APNS令牌；
• 另一个项目专门处理Location Push，客户端单独初始化这个项目的FCM实例，绑定Location Push的APNS令牌；
• 客户端把两个项目对应的FCM令牌都上传到后端，后端发送不同类型推送时，使用对应项目的FCM令牌调用接口。
  这个方案的好处是依然能利用FCM的生态，缺点是需要维护两个Firebase项目，配置和管理成本会高一点。

方案三：动态切换FCM绑定的APNS令牌（应急方案） #

如果上面两个方案都暂时无法落地，可以试试动态切换令牌，但这个方案有局限性：

• 客户端在需要接收特定类型推送前，主动调用setAPNSToken切换到对应的令牌。比如：
  • 进入需要接收Location Push的页面时，切换到Location的APNS令牌；
  • 离开该页面后，切换回常规APNS令牌。
• 但这个方案的问题很明显：如果用户同时需要接收两种推送（比如后台挂着的时候既可能收到常规通知又可能收到Location Push），就会顾此失彼，所以只适合场景单一的应急情况。

另外补充一点：iOS的Location Push令牌是和特定的推送服务绑定的，FCM本身并没有专门适配这种多令牌场景，所以前两个方案是更长期的解决思路。

备注：内容来源于stack exchange，提问作者Heps