00 / 00
推送通知
移动端推送通知的最小链路、权限弹窗、token 和生产前检查
推送通知不是第一版 App 必须做的。只有当用户真的需要提醒——订单、任务、消息、会员状态变化——再接入推送。
本地提醒和远程推送先分清
Todo 到期提醒、每日晨报、习惯打卡这类场景，很多时候可以先用本地通知：App 在用户授权后，把提醒时间排进设备。订单状态、多人消息、服务端任务完成这类场景，才需要远程推送。
| 类型 | 适合场景 | 需要准备 |
|---|---|---|
| 本地通知 | Todo 提醒、每日晨报、定时复盘 | 用户授权、提醒开关、App 内调度逻辑 |
| 远程推送 | 服务端事件、多人协作、支付状态变化 | EAS projectId、APNs / FCM 凭据、设备 token、后端发送逻辑 |
如果只是 MVP 的提醒功能，优先从本地通知开始。等确认用户真的依赖通知，再接远程推送和后端 token 管理。
推送链路
用户授权
权限弹窗
->
App 获取 token
设备标识
->
后端保存
用户和设备绑定
->
发送通知
测试 / 生产
接入前先问
| 问题 | 原因 |
|---|---|
| 用户为什么需要通知 | 没价值的通知会降低留存 |
| 哪些事件触发通知 | 避免滥发 |
| 用户能不能关闭 | 通知必须可控 |
| 失败怎么处理 | 推送不是可靠消息队列 |
用户需要准备什么
| 准备项 | 用途 | 备注 |
|---|---|---|
| 通知场景和文案 | 决定什么时候打扰用户 | 先写清每天、每周、即时触发哪些通知 |
| 用户开关 | 让用户能关闭通知 | 至少区分 Todo、晨报、系统通知 |
| Expo / EAS projectId | 获取 Expo push token | 远程推送需要 |
| iOS / Android 推送凭据 | APNs、FCM 发送能力 | 正式构建前准备 |
| 后端 token 存储 | 把用户和设备绑定 | 退出登录、卸载、token 失效要清理 |
| 真机测试设备 | 验证权限、到达率和时区 | 模拟器不能覆盖所有推送行为 |
通知上线前要有退订路径。用户关闭某类通知后，App 和服务端都要尊重这个选择。
验收清单
- 首次请求权限的时机合理，不在打开 App 第一秒就弹无上下文权限框
- 用户拒绝通知后，页面能说明怎么重新开启
- Todo 到期提醒或晨报通知能在真机按时触发
- 远程推送 token 能保存到当前用户，退出登录后不会继续绑定旧用户
- iOS / Android 的通知标题、正文、跳转目标和时区都正确
- 后端发送失败、token 失效、用户退订时不会反复重试打扰用户
复制给 AI
请帮我规划 01MVP mobile 的推送通知接入。
请先判断这个场景适合本地通知还是远程推送，以及是否需要 Development Build。
只设计最小链路：权限、用户开关、本地调度或 token、后端保存、测试发送、退订。
不要把推送服务端密钥放进 App。这篇文档有问题？