两端的授权时机
苹果端需要显式弹出系统授权框才能拿到设备令牌，授权框一生只能弹有限次数，拒绝后只能引导用户去设置里开启。因此不要在启动瞬间就弹，等用户进入需要通知的场景再请求。
安卓端在较新版本上通知权限同样是运行时权限，用户拒绝后通知会被静默丢弃，代码里不会报错，排查时容易误判为推送通道问题。
两端都应该在申请前说明用途，并记录用户的选择状态。每次启动都重复请求授权不会再次弹框，只会让代码逻辑变乱。
令牌的获取与更新
两端都要把设备令牌上报到自己的服务端并与用户绑定。令牌会变化，重装、恢复备份、系统更新都可能导致变化，上报逻辑要可重复执行。
上报接口应当是幂等的，同一个令牌重复上报不产生重复记录。用户切换账号时要把旧账号与该令牌的绑定解除，否则会把通知发给前一个用户。
服务端按用户维度存令牌要允许一对多，一个用户多台设备是常态。发送时按令牌逐个投递并记录结果。
通道能力与送达
苹果端的推送依赖系统通道，应用被杀死后仍能收到通知类推送，但静默推送在后台被限制时不可靠，不能依赖它做关键数据同步。
安卓端各厂商有自己的推送通道，设备不在线时由厂商服务代收。不同厂商的到达表现差异较大，重要消息建议结合自有长连接做兜底。
通道选择要按消息类型区分：强提醒走系统通知，数据同步走静默或应用内拉取，两者混用会导致用户被无意义的通知打扰。
通知样式与跳转
点击通知后的跳转要能还原到具体页面，而不是总是回首页。两端的参数结构需要统一，服务端下发的字段要能被两端同一套逻辑解析。
应用在前台、后台、被杀死三种状态下点击通知的回调时机不同，需要在启动参数里也解析一次，否则冷启动点击会丢失跳转意图。
通知的分组、角标、声音在两端的配置项名称和能力不同，统一在一层封装里处理，业务侧只描述意图。
发送策略与链路排查
按用户本地时间控制发送时段，避免在深夜打扰。服务端需要保存时区信息，或者由客户端上报当前时区。
对同类消息做聚合，短时间内多条相同类型的通知合并展示。逐条发送会让用户直接关闭通知权限。提供细分的通知开关，让用户按类别控制，设置在服务端记录并生效。
两端都需要能查看推送链路的各段状态：是否成功提交到通道、通道是否接收、是否被用户关闭、令牌是否失效。缺失任何一段都会让排查无从下手。
测试环境与生产环境的推送证书、密钥是分开的，配置错误是常见问题。上线前用真实设备验证一遍完整链路，模拟器通常收不到推送。
