Buildfire通知批量操作异常及平台规则咨询

针对问题1：通知新增/取消的数量上限、请求静默失败的潜在因素 #

各端系统对应用调度通知都存在明确限制，且大量失败场景不会通过请求响应抛出异常：

• 硬数量上限
  • iOS端系统对每个应用的待调度本地通知（UNNotificationRequest）有明确的64条硬上限，超出该数量的新增请求会被系统静默丢弃，仅保留触发时间最早的64条，你提到的单周生成120-350条通知的量级已经远超该阈值。
  • Android原生系统默认待调度通知上限为500条，但国内各定制ROM（MIUI、ColorOS、OriginOS等）会将该阈值压缩至100-200条不等，超出部分同样静默失败，无错误返回。
• 静默失败的核心潜在因素
  • 短时间高频操作触发系统流控：用户修改账号信息时，数分钟内会连续触发2-4次全量取消+全量重建操作，系统会对短时间内高频的通知增删请求做节流处理，部分取消请求会被直接丢弃，根本未执行到系统通知存储层，这也是本地测试（操作频次低未触发流控）无法复现、线上用户却收到旧通知的核心原因。
  • 后台进程执行中断：如果批量增删操作运行在后台线程，应用切后台时系统会临时冻结进程调度，未执行完的增删请求会被直接中断，若日志仅记录请求发起动作、未记录实际执行结果，自然无法统计到异常。
  • 通知标识冲突：若取消旧通知时使用的标识非全局唯一，或重建通知时复用旧通知触发条件未做覆盖，系统会将新旧通知条目并存，不会自动替换旧条目。

针对问题2：除请求响应外的通知创建/取消结果核验方式 #

• 直接拉取系统层全量待推送通知列表做比对
  • iOS端可调用UNUserNotificationCenter.current().getPendingNotificationRequests(completionHandler:)接口，拉取当前应用所有已注册待推送的通知全量集合，和本地存储的预期通知ID做差集比对，即可精准识别未删除的旧通知、未创建成功的新通知。
  • Android端可通过NotificationManager.getActiveNotifications()获取已展示未清除的通知，结合AlarmManager中注册的待触发任务，拼接得到全量待调度通知列表做校验。
• 增加操作后二次兜底校验逻辑
  批量增删操作执行完成后，延迟3-5秒调用上述系统接口拉取待推送列表，核对本次操作涉及的通知ID状态是否符合预期：应删除的ID是否已不在列表中、应新增的ID是否已在列表中，若存在异常则补做对应增删操作。
• 从架构层面规避上限问题
  不要一次性提交未来7天的全量通知到系统，改用滚动调度策略：每次仅向系统提交未来48小时内需要触发的通知（总量不会触发iOS 64条的硬上限），在应用启动、用户修改账号信息、收到远端推送等时机，自动校验并清理过期/无效的旧通知，补全下一周期的新通知，从根源上避开数量上限和高频操作流控问题。

注意：所有校验逻辑不要依赖本地操作日志，必须以系统接口返回的实际待推送通知列表为准，本地日志仅能记录请求发起动作，无法代表系统实际执行结果。

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