你说的现象，是算法逻辑范围内的情况，不是bug。

理论上：原因是，对方退到后台时，被系统挂起，对于服务端来说，它相当于非正常退出，而服务端并不知道，在服务端的会话超时到来前（这个时间默认是10秒），如果恰好在这个时间窗口发送消息，会认为对方在线，等对方应答包过来，而实际对方不会在线，那么就会出现发送方这边收到发送失败提示。

实际产品中：两个人聊天，其实人的手速和语速并不会太快，聊天消息恰好落在这个10秒窗口内的概率很小，另一个，当发送方的QoS重传次数到达极限前，可能服务端的超时就已经知道了对方超时退出，而这条消息也就会自动作为离线消息存储到服务端。

纸上谈兵式的暴力测试：开发的时候，可能会故意在这个时间窗口模拟一下子发送很多消息，那是有可能多条消息都会提示失败。但实际的产品中，谁这么聊天，要么那个人是机关枪，要么就是专门骚扰人的，消息失败就让它失败，无所谓。

总之：对于MobileIMSDK的算法（或者很多其它im的算法）来说，QoS送达保证机制的主要目的是：保证消息不会凭空消息（送达还是未送达），所以，即使你说的这种现象，它也算是明确告诉你消息未送达，而不是出现消息黑洞，这算法也是完整、合格的。

引用：Elley 发表于 2020-03-07 15:03
我现在返回后台，主动退出im登录，app打开后重新登录；如果大量用户使用，这样会有问题吗

你这句：“我现在返回后台，主动退出im登录，app打开后重新登录；如果大量用户使用，这样会有问题吗”

》要么是你没理解我说的，要么是我没理解你说的。。。

引用：麦峰强 发表于 2020-04-25 11:20
正确的系统不应该这么设计吧，应该是服务器充当中间者角色，当发送方发送后，到达服务器就应该是认为发送 ...

MobileIMSDK 从v5.0后，就是你说的这种逻辑了，你可以去看一下。