短信状态回执缺失、重复或晚到，应该怎样排查？

先分清"短信没发出"，还是"回执没收到"

这两件事的处理方式完全不同，却最容易被混为一谈。

看到"没有状态"，先别急着重发——它可能只是回执没回来，短信其实早到了用户手机上。

怎么判断：如果平台侧显示"已送达"，说明短信发出去了，问题出在回执往业务系统回传这一段；如果平台侧也查不到，才可能是没受理。

先认识三个词，后面的内容都靠它们串起来：通道指短信实际发出的链路；流水号指每条短信在平台侧的唯一编号；回执指通道把"是否送达"返回给业务系统的那条状态。

三种常见现象，可以对照着看：

● 缺失：平台显示已送达，业务系统里却没有记录

● 重复：同一条回执被推送了多次，通知或统计被重复计算

● 晚到：日报已经生成，回执才到达，归属哪一天成了问题

需要提前说明的是：网络波动可能造成同一条状态被重复推送，业务系统需要具备"同一条回执只处理一次"的能力；批量发送时，多个接收号码可能共用一个批次编号，因此不能只凭批次编号判断是否为重复。

判断卡在哪一环，可以对照下面这张表：

排查前，先备好这四类信息

排查回执问题，本质上是"找到同一次发送，再逐环节核对"。下面四类信息建议在日常就留存，不要等到出问题再补。

为什么这四类缺一不可：只知道业务编号，找不到是哪一次发送；只知道流水号，无法判断这条状态该更新哪条订单；不记录"收到时间"，就无法区分是通道晚发还是系统晚收。

具体的字段名称、可查询的时间范围、接口校验方式和重试规则，各通道并不一致，需要在项目对接时逐一确认

按现象一步步查

建议先挑一条有明确业务编号的样本，沿同一条链路逐环节核对。同时检索多个项目或跨日期一起查，很容易把另一次发送的状态当成当前结果，越查越乱。

其中"发送成功但用户没操作"这一行尤其容易被误判：回执显示送达，只说明消息到达了手机；用户是否看到、是否愿意操作，属于业务环节，两者不要混在一起判断。逐项核对时可以参照下面这张表：

回执异常时，可以直接补发吗

不建议。回执出问题和短信没发出，是两件事。

补发前建议先确认业务本身是否仍需要这条通知。这里要区分两个动作：补齐回执是把缺失的状态补上，属于状态修复；重新发送是产生一次新的触达，属于业务决策。两者需要分别确认，不能因为"看不到回执"就自动触发重发。

补发前建议先确认业务本身是否仍需要这条通知。这里要区分两个动作：补齐回执是把缺失的状态补上，属于状态修复；重新发送是产生一次新的触达，属于业务决策。两者需要分别确认，不能因为"看不到回执"就自动触发重发。

找我们支持时，可以先准备这些信息

信息越完整，定位越快。建议按下面清单准备一个"最小问题包"：

上线前，先验证这三种情况

业务系统能正常接收一条回执，还不代表异常情况下也能正确处理。建议在测试环境用指定的测试号码和测试业务事件验证下面三种情况，不要拿真实客户名单反复试。

这三个场景覆盖了回执异常的绝大多数情况。如果都能正确处理，说明恢复路径是可靠的；任何一项没通过，建议先修复再上线，避免正式发送时状态错乱。