使用FCM时，服务器如何判定客户端Token已失效？

一、Token失效的核心判定逻辑 #

FCM Token失效的典型场景包括：应用卸载重装、设备恢复出厂设置、用户清除应用数据、Token到期自动轮换（客户端通常会主动更新新Token）。要判定Token是否失效，核心依赖FCM的推送反馈机制：

• 当向失效Token推送消息时，FCM服务器会返回**未注册（Unregistered）**状态，此时Python的FCM SDK会触发messaging.UnregisteredError异常。这个机制是FCM官方提供的，可靠性很高——毕竟Token的生命周期由FCM服务器直接管理，只有它能精准判断Token的有效性。
• 注意：卸载应用后不会立即标记Token失效，FCM存在缓存周期（可能几小时到几天），直到它尝试向该Token推送时确认无法送达，才会将其标记为未注册，后续推送请求才会触发异常。

二、Python中messaging.UnregisteredError的可靠性 #

这个异常是完全可靠的，属于FCM SDK的标准错误反馈：

• 只要触发该异常，就说明对应Token已彻底失效，无法再用于推送，必须从后端数据库中移除。
• 无需额外校验逻辑，捕获异常后直接清理对应Token记录即可。

三、测试Token失效的实操方法 #

1. 应用卸载重装测试 #

• 在测试设备安装应用，获取并上传Token到后端。
• 卸载应用后立即尝试推送，此时可能不会触发异常（FCM缓存未更新）。
• 等待12-24小时（FCM缓存更新周期）后再次推送，此时应能触发messaging.UnregisteredError。
• 也可以卸载后重装应用，新生成的Token与旧Token完全不同，向旧Token推送，通常几小时内会触发异常。

2. 设备初始化/清除应用数据测试 #

• 在测试设备获取Token并上传。
• 清除应用所有数据（或恢复设备出厂设置），重新打开应用会生成新Token。
• 向旧Token推送，等待数小时后会触发失效异常。

3. 主动验证异常处理逻辑 #

• 故意使用篡改后的无效Token（比如修改原Token的几个字符）发起推送，测试是否能正确捕获messaging.UnregisteredError，验证后端异常处理逻辑是否正常。
• 借助Firebase控制台向目标Token重复推送失败请求，可加速FCM标记该Token为未注册状态。

四、额外优化建议 #

• 推送时除了处理messaging.UnregisteredError，还要覆盖其他错误类型（如messaging.InvalidApnsToken等），确保Token管理的完整性。
• 客户端应在Token更新时主动向后端上报新Token，提前更新记录，减少对失效Token的无效推送尝试。

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