3. 核心功能实现：推送通知

推送 是移动应用的“再唤醒引擎”，也是闭环增长中唯一能够主动触达用户的渠道。一次成功的推送意味着你在用户刚刚停下刷剧时提醒他领取优惠券，在骑车到家前提前告知外卖即将送达，或是在他决定离开产品前拉他回到关键流程。真正的难点不在于技术栈会不会，而在于 “用户画像 × 合适时机 × 有价值的内容 × 正确的落地体验”。

本章节以 Expo 技术栈为主线，从 0 到 1 构建一个简单但完整的推送体系。

一、推送架构：APNs、FCM 与 Expo Push Service

移动推送涉及多个角色：设备与操作系统负责接收，Apple 与 Google 提供的原生推送网关负责传输，Expo Push Service 站在中台位置替我们做协议适配，而业务服务端承担“发什么、发给谁”的决策。理解链路中的分工，是我们后续定位问题、规划架构的前提。

我先描述一下原生写法的流程：在 iOS 里，APNs 是唯一合法的系统推送入口。应用首次启动会向系统注册，系统返回一个 device token，服务端需要携带 APNs 证书或 p8 Token Auth 向 Apple 的网关发送推送请求，Apple 再将消息投递到目标设备。整个过程强制使用 TLS，Apple 还提供了 VoIP、Live Activities 等附加能力。

Android 则以 Firebase Cloud Messaging (FCM) 为核心：客户端和 Google Play services 交互获得 registration token，服务端填入 Server Key 调用 HTTP v1 API。它支持把通知直接交给系统渲染，也支持只传输数据由应用自行决定表现形式。

Expo Push Service 相当于两者之上搭了一层“代发平台”。客户端通过 expo-notifications 获取的并不是 APNs 或 FCM 的 token，而是 Expo Push Token。你的服务端将推送请求发送给 Expo，Expo 再将消息路由到 APNs 或 FCM，并处理批量分片、速率限制和重试，还会统一返回错误码，避免我们直接面对各家规范。

链路大致长这样：

客户端 (expo-notifications)
   |  注册并拿到 Expo Push Token
   v
业务服务端 (存储 Token / 触发推送)
   |  调用 Expo Push API
   v
Expo Push Service (校验 / 分片 / 重试)
   |  转发至 APNs / FCM
   v
目标设备 (系统策略决定呈现方式)

真实项目中，链路上最容易被忽视的点集中在三个方面。

1. Token 生命周期：同一个人可能同时使用两台手机，还会在不同账号间切换，如果不做好标签绑定和过期处理，就没法推送到正确的手机上。
2. 环境隔离：开发、预发、生产的证书或 Server Key 一旦混用，测试同学一键触达全量真实用户的事故那就是。
3. 网络可达性：跨境网络抖动会让 Expo/FCM 无法访问，提前准备连通性检测脚本能省掉半天排查时间。

二、平台凭证与权限配置

推送的可达性首先取决于 凭证 是否正确、权限 是否提前声明。我们可以先装好依赖并把配置集中在一处统一管理：

npx expo install expo-notifications expo-device expo-constants

// app.config.ts
export default {
  plugins: [
    [
      'expo-notifications',
      {
        icon: './assets/notification-icon.png',
        color: '#4f46e5',
        mode: process.env.APP_ENV === 'production' ? 'production' : 'development',
        sounds: ['./assets/sounds/order.wav']
      }
    ]
  ],
  ios: {
    supportsTablet: false,
    infoPlist: {
      NSUserNotificationUsageDescription: '我们将为你推送订单进度、优惠提醒等重要消息'
    }
  },
  android: {
    googleServicesFile: './android/app/google-services.json'
  },
  extra: {
    projectId: process.env.EAS_PROJECT_ID
  }
}

iOS 凭证与权限配置

APNs 凭证决定了谁能代表你的 App 与 Apple Push Notification service 通信。常见形态有旧版的 .p12 证书和新版的 APNs Auth Key（.p8）。证书需要针对 Development、Production 分别生成，且每次续期都要重新导出；Auth Key 则是 JWT 方式，一把 Key 最多绑定 10 个 Bundle Identifier，可随时吊销，是 Expo/EAS 场景的首选。

完整落地可以拆成几个明确的动作：

1. 在 Apple Developer Account 创建 App ID，开启 Push Notifications 能力，并在 Certificates, Identifiers & Profiles → Identifiers → App IDs 判断是否需要额外的通知扩展。随后到 Certificates, Identifiers & Profiles → Keys 生成 APNs Auth Key，勾选绑定的