Flutter更新原生App后出现重复推送通知问题咨询

两个Token完全不一致。
FCM Token的生成绑定三个核心维度：对接的Firebase项目、应用的包名+签名、当前设备上的Firebase实例。你新旧版本对接的是两个独立的Firebase项目，本身就不具备生成相同Token的前提；哪怕是同一个Firebase项目，Flutter端初始化FCM时读取的是自身插件管理的Token缓存，和旧原生代码存储在本地的Token也不属于同一个生成上下文，不可能相等。两个Token分属两个独立的推送下发通道，服务端同时向两个列表发消息，同一台设备自然会收到两条重复推送。

不需要依赖设备唯一标识，可按优先级落地以下方案：

• 端侧一次性清理旧Token：同包名覆盖安装不会清空应用沙盒数据，Flutter新版本首次启动时，可直接读取旧原生版本存储旧FCM Token的本地文件（Android端为SharedPreferences、iOS端为NSUserDefaults，只要确认旧版本存Token的字段key即可读取）。拿到旧Token后立刻上报服务端，将该Token从旧版本的推送列表中移除，同时本地写入一个永久标记位，避免后续启动重复执行该清理逻辑，清理完成后再上传新版本的FCM Token到新列表。
• 端侧推送内容去重兜底：所有推送消息无论走新旧哪个Firebase通道下发，都在消息载荷里携带全局唯一的消息ID。端侧收到推送后，先查询本地最近7天内的消息展示记录，如果存在相同ID的消息已展示，直接丢弃当前消息不再弹窗。该逻辑完全不依赖账号体系，端侧独立即可完成，适配所有场景。
• 服务端Token有效性自动清理：每次向旧版本Token列表下发推送前，批量调用Firebase提供的Token有效性校验接口，自动剔除已失效、对应设备已升级到新版本的Token，连续2-3个灰度周期后，旧列表中残留的已升级设备Token会被全部清理完成。

注意：不建议通过采集设备硬件唯一标识做跨列表匹配，该方案在Android 10+、iOS 14+系统上存在明确的合规风险，后续应用上架审核很容易被拒。

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