QET全俄通app 询盘消息通知推送用户卸载app，厂商什么时候返回给云函数失败状态

欢迎到专业群（ uniCloud 官方技术交流群 ） 咨询，群中有相关专业的管理员和群友。

好的，我们来分析一下这个问题。

你遇到的情况很典型：云函数推送返回成功，但用户卸载了App，手机收不到。问题的核心在于推送服务端（个推）的返回状态与实际送达情况之间有时间差和机制差异。

厂商何时返回失败状态？

厂商并不会实时、主动地通知你的云函数“这个用户已卸载”。失败状态的返回，依赖于下一次推送尝试以及你调用的API类型。

根据 uni-push 的官方文档和个推的机制，可以分为两种情况：

1. 调用 sendMessage（实时推送）
当你调用 uniPush.sendMessage 时，返回的 success 仅代表个推服务端成功接收了你的推送请求，不代表消息已送达设备。此时，如果用户已卸载，个推会尝试通过厂商通道下发，厂商通道检测到应用卸载后会返回失败，但这个失败状态不会同步反映在 sendMessage 的返回值中。

2. 调用 getTaskStatus（查询推送结果）
这是获取真正送达状态的关键。你需要使用 sendMessage 返回的 taskid，调用统计查询API来获取详细的折损原因。

在 uni-push 服务端API文档 的“获取推送实时结果”部分，明确列出了折损详情分类。其中：

• 折损大类 5：明确表示 “设备/应用无效（卸载）”。
• 折损大类 13：表示 “无效设备”。

所以，厂商会在个推的下发统计中，将卸载用户归入这些折损类别。你的云函数无法在调用 sendMessage 时实时感知，但可以通过定时任务或异步逻辑去查询 taskid 的状态，根据返回的 5 或 13 这类错误码来判断并清理无效的 clientid。

你的处理逻辑应该如何优化？

基于以上原理，建议你采用以下方案来自动清理无效CID：

1. 记录 taskid：在云函数调用 sendMessage 成功后，将返回的 taskid 和对应的 push_clientid 暂时存储起来（例如存到一张临时数据库表里）。
2. 创建定时查询云函数：编写一个定时触发的云函数，周期性地（例如推送后 5-10 分钟）去调用 getTaskStatus 接口，查询之前记录的 taskid。
3. 解析结果并清理：在 getTaskStatus 返回的详细数据中，检查每个 clientid 的折损详情。如果发现其 failed_detail 里包含了 5 或 13 这样的错误码，就可以判定该设备已卸载或无效，然后从你的数据库中删除这个 push_clientid 记录，避免后续资源浪费。

补充说明：
push_clientid 本身也有有效期。根据对话知识库中提到的信息，push_clientid 如果 3 个月未登录就会失效。所以，即使没有卸载，长期不活跃的 clientid 最终也会失效。定期清理无效CID是一个很好的资源管理习惯。

希望这个解释能帮你理清思路，优化你的推送和资源管理逻辑。