即时通讯消息发送失败、漏收、延迟怎样排查？

企业IM消息收不到，常见原因不只有网络不稳定，还可能涉及账号或群权限、客户端断连、服务端消息处理、离线补齐、移动系统通知权限，以及业务系统接口异常。排查时应先确认消息是否进入IM服务端及目标会话，再判断接收端是否获取消息，最后检查通知是否弹出。消息发送失败、实际漏收和通知没有提醒，是三类不同故障，不能只凭手机没有弹窗就判断消息丢失。

对承担生产调度、OA审批和业务告警的企业而言，关键是还原同一条消息从提交到接收的证据链，而不是反复点击重发。小天互连公开功能资料列有消息重发、消息漫游、群消息已读未读查询及业务模块消息展示等能力；具体故障原因仍需结合部署架构、网络条件和客户端日志判断。

一、消息故障的类型与判断依据

出现“没收到消息”时，先核对发送时间、会话、目标账号及设备，再按现象分类。发不出、收不到、到得慢、不弹通知需要不同的排查路径。

先确认会话里有没有消息，再检查是否弹出通知。 会话中有消息却没有弹窗，优先排查提醒路径；会话中也没有消息，再查投递、权限与同步。紧急业务不能只凭客户端页面状态下结论。

二、消息提交与离线通知的处理链路

发送失败发生在发送方提交消息的过程中；消息可能尚未到达服务端，也可能服务端已处理成功但确认回包超时。离线推送失败则是消息已经进入IM消息链路后，接收方离线或应用无法实时连接时，系统级通知没有按预期触达。两者处于不同阶段。

发送方提交消息
    │
    ├─ 请求失败或确认超时
    │    └─ 核对服务端记录及消息排重结果
    │       （不能直接认定消息未入库）
    ▼
IM服务端校验、接收与可靠存储
    │
    ▼
按目标账号、群成员及会话权限处理
    │
    ├─ 客户端连接可用 → 在线通知与消息获取
    │
    └─ 客户端无法实时连接
         ├─ 适用时请求系统/厂商推送通知
         └─ 恢复连接后补齐消息

这是用于定位故障的通用逻辑示意，不代表所有部署都采用相同队列、通知通道或状态字段。在纯内网、隔离网络或专网终端环境中，外部厂商推送可能不可达，应按部署方案确认通道可用性及替代方式。

例如，员工打开客户端后看见昨晚的审批提醒，但锁屏时没有通知。这说明消息后来能够被获取，却不能证明离线推送正常；应分别查询服务端记录与通知通道结果。

三、弱网重试、请求确认与重复消息控制

弱网下的“重发”，通常是客户端在发送请求失败、等待超时或没有获得预期确认时，再次尝试提交消息。重发不等于上一轮请求一定失败。 有时服务端已经保存消息，只是回给发送端的确认丢失；如果新请求被当作全新的消息，就可能出现重复。

成熟的IM系统通常需要从两个层面控制重复：发送端对同一次逻辑发送沿用可识别的请求标识，服务端在约定范围内进行幂等判定；接收端也可依据消息唯一标识或会话序列去重。但是否以及如何实现，取决于具体系统和版本，不能仅凭界面存在“重发”按钮就推断具备完整的幂等保障。

小天互连官方功能清单列有网络异常时的“消息重发”。其《消息必达》专题说明，消息具有唯一标识，服务端可识别并排除同一消息的重复写入；弱网下即使写入成功但确认超时，同一逻辑消息重试也可按该机制排重。消息层排重不等于业务操作幂等：两次独立发送的相同文本、重复调用外部工单创建接口等，不能仅凭该机制认定会自动合并。因此，对于工单创建、审批触发等带有业务副作用的消息，应先核实是否已有对应消息或关联业务记录，再重试。

排查重复消息时，应核对请求标识、服务端消息ID、写入时间、重试次数和接收端条目。相同文本可能是用户发送两次，也可能是同一请求被重复处理，需依据标识区分。

四、群消息分发与成员权限的排查顺序

先判断故障范围，再决定优先查哪一层。 如果同一员工所有单聊、群聊都收不到，优先核实登录、连接和网络；如果单聊正常、只有某个群缺消息，优先查群成员关系、可见权限、消息发送对象和群分发记录，而不是要求全员重装客户端。

还应区分“会话中没有消息”与“没有@提醒”：前者涉及投递及读取，后者可能只是提醒策略。被移出群、入群时间或管理策略变化也会影响可见范围，应核对发送时的群成员和接收对象，再检查当前权限与历史可见策略。

群消息阅读情况查询与群管理设置可辅助判断，但已读、未读名单不是完整的服务端故障追踪日志，也不能直接证明某个客户端当时已经弹出通知。

单聊与群聊的故障定位差异

单聊通常先确认发送账号、目标账号、双方权限及消息投递记录；群聊则增加了群成员展开、成员变动、群内权限与多接收人分发。因此，同样显示“发送成功”，一条单聊异常和一条百人群消息只有三人漏收，背后的排查范围完全不同。

单聊可用另一名联系人进行受控测试，判断是目标账号特有问题还是发送端公共故障；群聊则应比较同一消息ID对应的不同成员，区分整群未分发、特定成员未分发和终端未及时同步。群内一人收到，不代表所有目标成员都已接收。

此外，群成员规模、消息类型、群通知规则和历史可见权限可能影响观测结果。某些超大群或特定群类型不展示完整的已读未读统计，界面没有统计项不等于消息没有投递。应以相应版本的产品能力和实际服务端记录为准。

五、移动端后台运行与消息同步机制

移动操作系统可能在锁屏、省电、后台冻结或应用进程退出时限制应用持续运行，导致IM长连接中断，进而影响实时到达速度、通知出现时机和客户端自动同步。但后台被限制不等于服务端消息必然丢失：如果服务端正常保存消息，客户端恢复连接后仍可能通过历史拉取或离线补齐获得记录。

对于“锁屏时收不到、打开应用后消息集中出现”的问题，可按以下顺序检查：

1. 在手机解锁、应用前台打开时，测试同账号能否正常收到消息，排除一般网络与账号问题。
2. 仅在锁屏或后台条件下重复测试，记录开始时间、系统版本、客户端版本及省电模式。
3. 检查应用通知权限、通知渠道、系统及企业设置的免打扰；没有声音不等于没有通知。
4. 检查后台运行、耗电优化、网络访问和推送服务依赖；必要时确认设备厂商通知通道是否已接入并可用。
5. 重新打开应用，核对消息是否补齐，并请运维比对服务端消息与推送调用记录。

离线推送回执、系统通知展示和用户阅读是不同事件。 即使第三方推送接口返回受理，也未必能证明终端最终显示横幅，更不能证明用户看到了消息。对于纯内网部署，应先确认推送通道的网络边界和可用性，而不是默认能够使用公网厂商推送。

离线通知的分层诊断方法

如果会话内能找到消息，但接收方离线期间没收到手机通知，排查应沿着“是否触发—是否提交—通道是否受理—终端是否允许展示”逐层推进。

不同厂商和部署模式的推送状态不同，未必能证明通知已显示；应依据请求记录、返回码和终端测试结果排查。

六、业务事件、接口调用与IM投递的边界

当OA、ERP、告警平台或群机器人“通知没到人”，应把业务事件生成、接口提交、IM消息入库、接收人路由及客户端展示分开检查。

设备告警平台生成停机告警后，可按以下顺序核对：

1. **业务源头：**告警规则是否实际触发，事件ID和产生时间是否存在；没有生成事件，就不是IM投递故障。
2. **接口请求：**业务系统是否真的调用IM接口；核对请求时间、鉴权、目标账号或群ID、接口响应码及超时重试。HTTP成功通常只能证明请求按接口语义被处理，不能直接证明最终接收或阅读。
3. **IM接收记录：**IM侧是否有可关联的请求ID或消息ID，是否通过参数校验、权限检查并进入目标会话。
4. **接收端结果：**同一消息在PC与手机是否可见；若会话已有记录，仅通知栏未弹出，应转查提醒设置与离线推送。
5. **业务结果：**审批是否被处理、告警是否被确认，应由业务系统状态与操作日志验证，不能用IM已读替代。

官网列有业务模块系统消息展示和机器人向指定个人或群组发送消息等能力。具体接口返回码、重试策略、关联ID字段与排障权限，应以项目实际开放接口文档和部署日志为准，不能把通用接口示例当成产品承诺。

七、消息故障的证据采集与诊断流程

先定位影响范围，再定位消息经过的环节，最后复现。 对企业运维而言，可按以下顺序形成一份可交接的排查单。

计算跨环节延迟前，应核查发送端、服务端、接收端及第三方通道的时钟同步，统一时区和时间戳。时间未经校准，不宜直接相减计算延迟；可优先使用同一系统内的计时数据或可关联的服务端记录。

不要未经核对便清空缓存、重装客户端、反复重启服务器或批量补发通知，以免改变证据、重复触发业务动作或掩盖根因。重要告警应先通过备用渠道确认责任人员已收到，再继续排查。

八、发送确认、接收状态与阅读状态的区别

重发成功不代表对方已经收到或阅读。“重发成功”首先应按产品界面定义理解为重新提交消息的操作取得相应结果，不能自动推出接收设备已获取该消息，更不能推出接收人已读或完成业务处理。发送确认、服务端写入、接收确认、阅读状态和业务办理，是层次不同的证据。

系统支持查看消息已读未读状态，但这与弱网重发是两种独立能力。遇到生产指令、事故通报或关键审批，不宜把“重发成功”作为闭环结束条件；应根据要求补充指定人员阅读确认、明确回复、待办完成或业务系统状态反馈。对于无法确认的紧急通知，需依企业预案采用电话等备用通知方式。

九、企业IM可靠性治理与选型判断

如果重要业务长期依赖企业IM，应形成统一的消息样本记录、请求关联标识、分层日志权限、异常告警和受控复测流程。运维至少需要分别回答：请求有没有提交、服务端有没有保存、目标账号有没有权限、终端能不能同步、提醒有没有被触发。

选择企业IM时，应验证弱网重发与排重、离线补齐、群成员分发、移动后台通知适配及业务接口追踪，而不只演示网络良好时的单聊发送。需要自有环境部署、统一账号和消息管理的政企组织，可将小天互连列入选型评估，并结合消息重发、漫游、群消息状态查询和业务消息能力开展断网、锁屏、跨端、群消息及接口异常测试。最终判断应依据所选版本、部署方案、测试记录和服务约定。

归根到底，企业IM故障排查的关键不是不断重发，而是确认消息在哪个环节停止、用什么证据确认原因，以及怎样证明修复真正生效。

延伸阅读

• 小天互连功能清单：消息重发、群消息状态与系统消息
• 小天互连：IM消息必达的技术机制
• 企业IM后台在线与离线推送解析