如何在Expo推送请求中传递ID并在响应中返回以关联原始数据

核心思路：绕开自定义Header限制，利用请求JSON字段或本地映射实现关联 #

Expo的推送API确实不支持自定义HTTP Header的回传，所以直接通过Header传递关联ID的方案不可行，推荐以下几种更稳妥的实现方式：

• 在请求的data字段嵌入业务关联ID
  调用Expo推送接口（比如POST /v2/push/send）时，在每个通知对象的data字段中加入你的业务唯一标识（比如系统内的消息ID、用户请求ID）。虽然Expo不会在返回的ticket中直接返回这个ID，但你可以在发送请求前，在本地记录下「业务ID + 请求参数」的映射，当收到包含ticket ID的响应后，直接通过请求参数中的业务ID完成关联。
  若是批量推送场景，Expo返回的tickets数组顺序与请求中notifications数组的顺序完全一致，你可以直接按索引对应，匹配每个ticket和对应的业务ID。

• 本地临时映射缓存
  发送请求前生成一个全局唯一的请求标识（比如UUID），将这个标识与你的原始业务数据绑定，存储到本地缓存（如Redis）中，同时把这个标识放到推送请求的data字段里。当收到Expo的响应后，取出响应中的ticket ID，结合请求里的标识从缓存中找到对应原始数据，完成关联后即可清理缓存。这种方式适用于需要异步处理响应的场景，避免请求响应直接绑定的耦合。

• 借助Expo推送回执Webhook
  如果你的系统支持接收Webhook回调，可以配置Expo的推送回执Webhook。发送推送时在data字段加入业务关联ID，当Expo推送状态更新（送达/失败）时，会在Webhook的回调 payload 中原封不动返回你传入的data字段，此时你就能通过回调中的业务ID关联到原始数据，同时拿到对应的ticket ID和推送状态。这种方式适合需要跟踪推送全生命周期的场景。

另外，你提到的「伪造token附加ID」的方法虽然能实现，但存在潜在风险——如果Expo后续对token格式做校验，可能导致请求失败，不建议长期使用。

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