您链接的答案中的解决方案存在问题.它会尝试在每条消息发送后读取错误响应,但读取会立即返回,并且不会等待响应变为可用.虽然这比在每条消息之后等待X mili-seconds的潜在错误响应更有效,但您可能会错过错误响应,Apple可能会在不知道发生任何错误的情况下断开连接.

虽然我不能给你代码来解决你的问题,但我会给你一些建议.

这是您应该使用的逻辑(根据Apple),但我没有设法让它可靠地工作(至少在我的Java实现中没有)：

这取自Apple的技术说明：Troubleshooting Push Notifications.

我不知道你在PHP中如何检测到写入失败,但是当它发生时,你应该再次尝试写失败的通知,如果再次失败,请尝试读取错误响应并关闭连接.

如果您设法读取错误响应,您将知道哪个通知失败并且您将知道错误类型(最可能的错误是8 – 无效的设备令牌).您提到的答案中的代码在识别出错误后没有做任何事情.
如果在写完100条消息后您收到第80条消息的错误响应,则必须重新发送消息81到100,因为Apple从未收到过消息.在我的情况下(Java服务器),我并不总是设法读取错误响应(有时我尝试从套接字读取响应时出错).在这种情况下,我只能继续发送下一个通知(并且无法知道Apple实际收到了哪些通知).这就是为什么保持数据库清除无效令牌很重要的原因.

如果您保持数据库清洁(即只存储由Apple发送到您的应用程序的设备令牌,并且它们都属于相同的推送环境 – 沙箱或生产),您不应该遇到任何无效的设备令牌.

在Java中实现推送通知服务器端时,我遇到了类似的问题.我无法可靠地获得Apple返回的所有错误响应.

我发现在Java中有一种方法可以禁用TCP Nagle算法,这会导致多个消息在批量发送到Apple之前缓冲.虽然Apple鼓励我们使用Nagle的算法(出于性能原因),但我发现当我禁用它然后在发送给他们的每条消息后尝试读取Apple的响应时,我设法收到100％的错误响应(I通过编写模拟APNS服务器的过程来验证它.

通过禁用Nagle算法并逐个发送通知,慢慢地尝试在每条消息之后读取错误响应,您可以在数据库中找到所有无效令牌并将其删除.一旦您知道您的数据库是干净的,您就可以启用Nagle的算法并快速恢复发送通知,而无需阅读Apple的错误响应.然后,每当您在向套接字写入消息时收到错误,您只需创建一个新套接字并重试仅发送最后一条消息.