Firebase推送通知返回成功响应，但手机未收到通知

这种情况真的挺挠头的——API返回完全正常，但就是收不到通知，而且官网用同一令牌发又没问题，还是在应用运行状态下，肯定是某个细节没对上。我帮你梳理几个最可能的排查方向，一步步来：

1. 对比官网请求，检查你的API Payload结构 #

官网发送的通知和你Postman调用的Payload大概率存在差异，核心是**通知消息（notification字段）和数据消息（data字段）**的区别：

• 如果你只在Payload里传了data字段，FCM不会自动帮你展示通知，需要客户端自己写代码解析并弹出通知；而官网默认发送的是带notification字段的通知消息，系统会自动展示。
• 给你一个能直接生效的通知消息Payload示例，你可以直接复制到Postman测试：

{
  "to": "你的设备令牌",
  "notification": {
    "title": "测试通知",
    "body": "这是来自Postman的测试通知"
  },
  "priority": "high"
}

• 另外，如果你需要同时传data和notification，确保两个字段都正确嵌套在根节点下，不要写错层级。

2. 确认请求的优先级设置 #

FCM的优先级直接影响通知的送达效率，尤其是Android设备：

• Android端必须在Payload里加上"priority": "high"，低优先级的通知可能被系统延迟甚至忽略，哪怕API返回成功；
• iOS端则需要设置"apns-priority": "10"，同样是确保通知能及时推送到前台运行的应用。

3. 检查客户端的FCM消息处理逻辑 #

虽然应用在运行，但如果客户端的消息处理代码有问题，也会导致通知“消失”：

• Android：检查FirebaseMessagingService的onMessageReceived方法，是不是正确处理了RemoteMessage中的getNotification()和getData()？有没有不小心过滤掉了某些类型的消息？
• iOS：检查didReceiveRemoteNotification或userNotificationCenter(_:didReceive:withCompletionHandler:)方法，是否正确调用了通知展示的逻辑，有没有因为权限或代码逻辑问题跳过了通知弹出？
• 额外确认：客户端获取的设备令牌和你Postman里用的是不是完全一致，有没有复制错误或者令牌过期（但官网能发的话，令牌应该是有效的）。

4. 验证API请求的身份认证 #

虽然API返回无错误，但还是要确认Postman的请求头是否正确：

• 确保Authorization头的值是key=你的FCM服务器密钥，这个密钥要和你Firebase项目的服务器密钥完全一致，别错用了其他项目的密钥。

5. 查看Firebase控制台的送达报告 #

去Firebase控制台的Cloud Messaging页面，找到你用Postman发送的消息记录，查看送达统计。这里会显示消息是“已发送”还是“未送达”，如果是未送达，控制台可能会给出具体原因（比如设备令牌无效、系统限制等），帮你快速定位问题。

6. 检查设备的通知权限和渠道设置 #

即使应用在运行，设备端的设置也可能拦截通知：

• 确认设备给应用开了通知权限，没有被手动关闭；
• Android 8.0及以上版本，需要确保你的应用创建了有效的通知渠道，官网发送的通知可能用了默认渠道，而你API发送的如果没指定渠道，可能渠道被禁用了。

最快速的排查方法其实是抓一下官网发送通知时的请求（用浏览器开发者工具的Network面板），对比你Postman的请求，看看Payload、请求头有什么不一样，通常问题就出在这里。

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