如何向指定的其他用户发送FCM推送消息？

现有方案的合理性 #

你目前构思的「将用户FCM token存储到数据库，触发业务事件时查询目标用户的对应token发送通知」的思路，本身是移动端单点推送的标准基础实现，不存在逻辑问题，优化方向主要是解决原生实现的常见缺陷，以及适配不同业务量级、多端场景的需求。

可落地的优化方案 #

• 存储结构优化：不要将FCM token直接绑定到用户主表，单独建user_device_tokens关联表，字段包含用户ID、FCM token、设备类型、上次活跃时间、失效标记。该方案可以支持单用户多设备同时登录（比如手机+平板同时在线）时，给所有有效设备下发通知，也可以定期清理超过3个月无活跃的无效token，降低FCM接口的错误请求占比。
• token生命周期自动维护：客户端每次启动/切到前台时，主动将当前最新的FCM token上报服务端做upsert（存在则更新活跃时间，不存在则新增）；服务端每次调用FCM接口返回InvalidRegistration/NotRegistered等token无效类错误码时，自动将对应token标记为失效，避免后续重复发起无效请求浪费资源。
• 业务逻辑与推送逻辑解耦：不要在业务代码中直接嵌入FCM调用逻辑，单独抽离通用推送服务层。业务侧（比如好友请求触发逻辑）仅需要向消息队列推送事件，推送服务消费事件后再查询目标用户的token批量发送通知。该方案在高并发场景下不会阻塞主业务流程，也方便后续替换推送服务商时无需修改上层业务代码。
• 国内场景下的多通道适配：如果产品面向国内安卓用户发布，仅用FCM会因为厂商后台进程限制导致到达率极低，可在客户端侧做厂商推送适配，不同品牌设备上报对应厂商推送（华为推送、小米推送、OPPO推送等）的token，服务端推送时根据设备类型选择对应通道，推送到达率会远高于单纯使用FCM。
• 高优先级通知的双保险机制：针对好友请求、私信这类对到达率要求高的场景，可以先下发带业务标识的静默推送，客户端收到静默推送后主动拉取最新业务数据，再本地生成通知弹出，避免FCM payload大小限制、传输丢包导致的通知内容异常问题。

关于方案选择的建议 #

如果你的产品DAU低于10万，且没有多设备登录、国内安卓适配的需求，最开始的基础实现方案完全够用，不需要做过度设计，可以等业务量级上升后再逐步迭代上述优化点。

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