TG咨询服务端实例重建后，推送令牌通常还能用：令牌由推送服务和客户端应用共同管理，并不因为一台服务器重启或重新部署就自动失效。移动应用推送令牌在实例重建后的续用策略，首先取决于你重建的是服务端，还是用户设备上的应用实例。
先分清“实例”指什么
如果重建的是云主机、容器或应用服务，且令牌数据库、推送凭证和项目配置仍然可用，原令牌一般可以继续发送。反之，若数据库没有恢复、环境变量缺失，或新实例连接到了不同的推送项目，即使令牌本身有效，也可能无法送达。
如果重建的是手机端应用实例，情况不同。卸载重装、清除应用数据、换机或系统恢复，都可能导致客户端重新向推送平台注册并取得新令牌。旧令牌不能被当作永久有效的设备标识。
| 变化场景 | 常见影响 | 建议 |
|---|---|---|
| 服务端进程或容器重建 | 令牌通常不变，服务配置和令牌库可能出问题 | 恢复持久化数据，核对项目凭证并发送测试通知 |
| 应用卸载重装或清除数据 | 客户端可能取得新令牌 | 应用启动后重新上报并更新绑定 |
| 更换设备或用户退出 | 令牌对应的设备或账号关系改变 | 解绑旧关系，避免继续向旧设备推送 |
推送平台的令牌不是永久凭证
Firebase Cloud Messaging
Firebase Cloud Messaging（FCM）的注册令牌可能在应用恢复、重新安装或令牌刷新等情况下变化。客户端应处理令牌更新回调，并把新令牌发送到自己的服务端；服务端则按应用、设备和账号关系更新记录，而不是只在首次登录时保存一次。
Apple Push Notification service
Apple Push Notification service（APNs）的设备令牌也可能变化。iOS 应用应在系统注册成功后取得当前令牌并上报。服务端收到 APNs 返回的无效设备令牌等错误时，应停止向该令牌发送，并安排客户端下次注册后重新绑定。
实例重建后的核对步骤
确认重建范围：是服务端机器、容器，还是客户端应用。检查服务端令牌数据库是否使用持久化存储，不能把唯一副本留在临时磁盘或内存中。
核对推送环境：检查 FCM 项目凭证，或 APNs 使用的密钥、主题与环境配置。测试环境和正式环境的配置不要混用。
让客户端在启动及令牌刷新时上报当前令牌。服务端使用幂等更新，避免同一令牌反复创建多条设备记录。
向测试设备发送一条通知并检查平台回执。成功提交不代表用户一定看见通知；设备离线、系统通知权限关闭或应用状态都可能影响呈现。
按推送错误清理失效令牌，同时保留足够的诊断信息，例如平台、环境、错误类型和发生时间。不要在普通日志中长期记录完整令牌。
令牌续用的关键：更新绑定，而非永久保留
移动应用推送令牌在实例重建后的续用策略，应把令牌视为可更新的路由信息，而不是账号身份凭证。建议记录令牌所属平台、应用环境、最近更新时间及关联账号；同一设备切换账号时更新绑定，用户退出时按产品规则解除账号关联。令牌本身也不应单独用于证明用户身份。
如果仅重建服务端且数据、凭证均已恢复，不必要求所有用户重新安装应用。若客户端实例发生变化，则以客户端新上报的令牌为准；旧令牌是否仍可发送，最终以推送平台的响应为判断依据。做好持久化、刷新上报和失效清理，才能让移动应用推送令牌在实例重建后的续用策略稳定落地。
常见问题
服务端重启后要让用户重新授权通知吗？
通常不需要。服务端重启不会自动改变设备的通知权限；只有应用权限状态或系统设置改变时，才需引导用户检查授权。
旧令牌还能发送成功，就可以一直保留吗？
不建议。它可能已经不对应当前账号或设备。应结合客户端更新、用户退出和平台错误及时维护绑定。
用户换机后能沿用原令牌吗？
不能假定可以。新设备通常需要重新注册并上报自己的令牌，服务端再按账号关系更新设备记录。