Node.js发送FCM推送报注册令牌无效问题排查与修复

开发者阿泽

2026-9-2

问题根因说明

首先纠正一个认知误区：你观察到的accessToken包含大量点号是正常现象——FCM HTTP v1接口鉴权用的OAuth2令牌本身是JWT格式，结构为头部.载荷.签名，三段用点分隔，这个特征和报错没有任何关系，不需要在这个点上耗费排查时间。

你遇到的The registration token is not a valid FCM registration token（INVALID_ARGUMENT）错误，本质是你传给FCM接口的客户端注册令牌不符合要求，高频触发原因按概率从高到低排列：

项目配置不匹配：Flutter端集成的Firebase配置文件（安卓的google-services.json、iOS的GoogleService-Info.plist）和Node.js后端使用的service-account.json不属于同一个Firebase项目，跨项目的令牌无法互相识别。
令牌值混淆：把后端鉴权用的带点JWT access token，当成客户端FCM注册令牌传到了message.token参数位，这是手写HTTP v1接口时最容易踩的坑，两个令牌生成逻辑、用途完全不同，混传100%触发该错误。
客户端拿到的令牌本身无效：用没有完整Google Play服务的模拟器、未正确配置Firebase的调试环境拿token，或者用了app卸载重装/清空数据后已经失效的旧缓存token。
请求结构错误：从旧版FCM HTTP接口迁移到v1时，把客户端token放到了已废弃的to字段，而不是v1要求的message.token字段，哪怕token本身正确，字段位置不对也会被判定为无效。

分步修复方案

第一步：先校验全链路项目一致性
打开Flutter端的Firebase配置文件，找到project_id字段，和Node.js端service-account.json里的project_id值做比对，必须完全一致。Flutter端初始化Firebase时建议直接使用默认的配置读取方式，不要手动硬传projectId等参数，避免配置错配。
第二步：拿到有效的客户端FCM注册令牌
测试阶段必须使用搭载完整Google Play服务的真机，不要用无GMS的国产安卓模拟器、未配置Google服务的iOS模拟器，这类环境生成的token本身不被FCM认可。
不要使用本地缓存的旧token，每次app冷启动时都调用FirebaseMessaging.instance.getToken()获取最新值，同时监听FirebaseMessaging.instance.onTokenRefresh流，token刷新时实时同步到后端。拿到token后打印全量值，确认没有被截断、没有多余空格或转义字符。

第三步：修正后端请求逻辑
如果是手写HTTP v1接口调用，严格遵循以下结构，不要混淆两个token的位置：

带点的JWT access token仅放在请求头Authorization: Bearer <你的access_token>中，绝对不能放到请求体里；请求体message.token字段只放Flutter端获取的客户端注册令牌。

// 正确的请求体示例
const requestBody = {
  message: {
    token: "Flutter端获取的客户端FCM注册令牌",
    notification: {
      title: "测试通知",
      body: "通知内容"
    }
  }
}
// 正确的请求地址格式：https://fcm.googleapis.com/v1/projects/<你的project_id>/messages:send

如果使用firebase-admin SDK发送，参考以下正确写法，同样注意不要传错token：

const admin = require("firebase-admin");
const serviceAccount = require("./service-account.json");

admin.initializeApp({
  credential: admin.credential.cert(serviceAccount)
});

admin.messaging().send({
  token: "Flutter端获取的客户端FCM注册令牌", // 这里不要传OAuth access token
  notification: {
    title: "测试通知",
    body: "通知内容"
  }
}).then(resp => console.log("发送成功", resp))
  .catch(err => console.error("发送失败", err));

第四步：最小链路验证
把Flutter端刚获取的新鲜token直接硬编码到后端测试代码中，跳过接口传参、数据库存储等中间环节，先跑通单条消息发送的最小流程，再逐步接入完整业务链路，避免中间环节截断、篡改token值。

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