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