Flutter开发中如何基于Firebase的timestamp字段触发通知？

基于Firebase云端的实现逻辑 #

Firebase没有直接按文档时间戳触发通知的开箱能力，需要组合现有服务搭建调度链路，核心步骤如下：

• 补全任务文档字段：在原有作业任务文档基础上新增3个字段，避免调度逻辑混乱：
  • remindTriggerTime：提前计算的提醒触发时间，值为作业到期时间戳减去用户选择的提前提醒时长（天/小时统一换算为毫秒值存储）
  • notificationSent：布尔标记位，初始为false，用来标记当前任务的提醒是否已经推送，避免重复发送
  • userFcmToken：对应用户的FCM设备注册token，从用户主文档冗余到任务文档，减少扫描时的跨集合查询
• 搭建定时扫描逻辑：使用支持定时触发的Cloud Functions，设置每10~15分钟执行一次任务扫描，规则为筛选出所有满足notificationSent == false 且 remindTriggerTime <= 当前UTC时间的任务文档
• 执行推送动作：扫描到符合条件的任务后，调用Firebase Cloud Messaging接口，向对应token的设备发送作业提醒，通知内容可以携带对应任务的文档ID，方便用户点击后直接跳转到作业详情页
• 状态回写：通知发送成功后，将对应任务文档的notificationSent字段更新为true；如果发送失败（比如token失效），不做强制重试，依赖FCM本身的离线消息缓存通道，等设备下次在线时自动送达
• 变更联动：监听任务文档的修改、删除事件——当用户调整作业到期时间、修改提前提醒时长时，自动重新计算remindTriggerTime，把notificationSent重置为false；当用户删除任务时，直接跳过该文档的扫描逻辑

这类方案的优势是通知到达率高，就算应用被强制关闭、设备临时关机，只要设备联网就能收到推送，不受本地应用运行状态影响。

客户端本地触发的实现步骤 #

这类方案完全在端侧完成调度，不需要编写云端逻辑，核心步骤如下：

• 依赖初始化：引入flutter_local_notifications、timezone两个核心库，在应用启动时完成设备本地时区的初始化，避免UTC时间和本地时间的计算偏差，导致通知触发时间错位
• 同步本地通知队列：每次应用启动、或从Firebase拉取到最新的任务列表时，全量同步本地的待触发通知：
  • 新增任务：将任务文档ID做哈希映射为固定的int类型通知ID（保证同一个任务的通知ID全局唯一且固定，避免重复注册），计算提醒触发时间（到期时间减去用户选择的提前时长），调用zonedSchedule方法注册本地通知，通知内容携带任务文档ID作为跳转参数
  • 修改任务：根据对应任务的哈希ID，先取消已经注册的旧通知，再按新的触发时间重新注册调度
  • 删除任务：根据对应任务的哈希ID，直接移除已经注册的本地通知
• 系统权限适配：
  • 安卓端：申请通知发送权限，引导用户将应用加入电池优化白名单，避免系统在后台杀进程导致通知调度中断
  • iOS端：应用启动时申请本地通知权限，配置通知点击的回调逻辑，确保应用在前台、后台、被杀死状态下都能响应通知跳转

这类方案的特点是实现速度快，没有云端函数的调用成本，但通知到达率受系统规则影响较大：当用户强制划掉应用、开启极端省电模式时，可能出现通知延迟、甚至不触发的情况。

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