iOS端Firebase Cloud Messaging首次推送通知失败问题

我之前也碰到过类似的Firebase通知延迟、得重复推送2-3次才到设备的坑，结合自己的排查经验和官方文档的提示，给你几个具体的排查方向和解决办法：

一、先检查Firebase Console的推送配置 #

• 调整通知优先级：Console默认的“正常”优先级在Android设备上很容易被系统休眠策略（比如Doze模式）延迟，直接改成「高优先级」试试——高优先级的通知会强制唤醒设备网络，能大幅提升送达效率。
• 确认推送目标的准确性：检查你选择的推送目标（单个设备/用户组/主题）是不是正确，有没有误选了多个重复的目标？不过你说重复推送才到，这个可能性相对小，但可以快速排查下。

二、排查设备端的系统限制 #

Android设备 #

• 关闭应用的电池优化：国内厂商（小米、华为、OPPO等）的定制系统对后台应用限制极严，把你的应用加到「电池优化豁免名单」里（路径一般是：设置→电池→电池优化→找到你的应用→选择“不允许”）。
• 确认应用的自启动权限：很多厂商会默认禁止应用自启动，即使FCM推送来了，应用也没法被唤醒接收，所以要开启自启动权限。

iOS设备 #

• 检查通知权限完整性：确保应用的「允许通知」完全开启，包括锁定屏幕、通知中心、横幅的权限，还要开启「后台App刷新」——这个是iOS后台接收推送的关键。
• 关闭低电量模式：低电量模式下iOS会限制后台活动，导致推送延迟。

三、排查FCM底层状态 #

• 查看FCM送达报告：在Firebase Console的「Cloud Messaging」板块，找到你推送的历史记录，查看「送达率」「延迟时间」「失败原因」——如果是平台侧的问题，这里会有明确提示；如果只有个别设备出现，那大概率是设备端的问题。
• 验证FCM令牌有效性：有时候设备的FCM令牌会过期或失效，第一次推送失败后，FCM会自动重试，而此时应用可能已经刷新了令牌，导致第二次/第三次才成功。你可以在应用里加个日志，每次令牌刷新时打印出来，确认当前使用的令牌是最新的。

四、排查网络环境 #

• 测试稳定网络：如果设备处于弱网（比如信号差的4G、不稳定的WiFi），第一次推送可能因为网络超时失败，FCM的重试机制会再次推送，看起来就是重复推送才到。换个稳定的网络环境测试下，看看是否还会出现这个问题。
• 检查防火墙/代理：如果设备在企业或校园网络下，可能防火墙拦截了FCM的端口（FCM使用5228、5229、5230端口），导致推送无法及时送达，需要确保这些端口是开放的。

五、额外测试技巧 #

你可以试试用FCM的API推送（而不是Console），手动指定高优先级参数：

• Android端：在请求体里添加"priority": "high"
• iOS端：添加"apns": {"headers": {"apns-push-type": "alert"}}
  对比API推送和Console推送的效果，如果API推送一次就能送达，那说明是Console的默认配置问题，调整Console的优先级即可。

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