设想一个熟悉的场景：手机放在桌上，一直没有提醒。过了一会儿，你打开 App，聊天列表突然多出好几条消息，时间却都是十分钟前。
对方说早就发了，你也确实没看到。手机明明连着 Wi-Fi，其他应用用起来没什么问题。
这种时候，很容易先怪网络。但"消息迟到"包含好几种不同的情况：数据没有到设备，应用没有及时处理，或者内容已经到了，只是系统没有显示提醒。
它们看上去相似，排查方向却不一样。尤其是后台消息，除了网络，还要看应用当时能不能运行。
发送方点下发送，不代表接收方的屏幕立刻有变化。
在一种常见实现中，业务服务器先接收并保存消息，再把推送交给推送平台；平台尝试送到设备，之后由系统或应用处理，最终才可能出现通知。不同产品的路径会有差别，有些还会在前台使用自己的实时连接。
这里每一步的"成功"，含义都不同。
| 记录到的事件 | 还不能据此确定什么 |
|---|---|
| 业务服务器已保存消息 | 接收方设备已经收到 |
| 推送平台已受理 | 消息已经送达设备 |
| 设备或应用已接收 | 通知已经展示 |
| 通知已发布到系统 | 用户已经注意到或阅读 |
以 FCM 为例，服务端成功提交消息，不代表消息已经交付到设备。设备离线时，消息可能根据有效期等条件被保留，之后再尝试投递。
所以，看到服务端的一条"发送成功"，先问这是谁记录的、成功到了哪一站。这个问题比马上调整丢包率更有用。
前台打开的应用，可以及时响应用户操作。退到后台以后，系统还要兼顾续航，不会保证每个应用一直像亮屏时那样运行。
以 Android 为例，Doze 会在设备满足相应空闲条件时限制或延后部分网络与后台活动；App Standby 则与应用近期是否被使用有关。锁屏只是观察条件之一，不能直接把"刚锁屏"当成"已经进入 Doze"。
这会造成一种容易误判的现象：网络路径本身没坏，但原本准备联网的任务还没有获得执行机会。
反过来，应用获得了执行机会，也不代表网络一定可用。后台限制与弱网可以同时存在，单看一个加载失败提示分不清它们。
不同系统版本、设备设置和推送方案会影响实际行为。测试时至少记录这些条件，不要把一台手机的结果概括成"Android 锁屏后收不到消息"。
提醒到了，详情可能还在路上
推送消息可以直接包含用于展示的内容，也可以只告诉应用"有更新"，再由应用联网取回详情。
假设推送只带了一个消息编号。它已经到达设备，但应用拉取正文时遇到超时。用户看到的，可能是没有内容的提醒，也可能什么都没有，取决于产品怎么处理。
此时，继续查推送平台为何不投递，方向就偏了。真正慢的是第二段访问。
能直接提供必要展示信息时，可以减少对这次额外访问的依赖；但放哪些内容还要考虑隐私、载荷限制和锁屏展示，不能把敏感正文一股脑塞进通知。
以 FCM 为例，普通优先级消息在 Doze 中可能延后，高优先级用于需要及时展示给用户的消息，并提供有限的处理机会。它不是无限后台运行许可，也不能保证后续拉取一定完成。把所有同步都改成高优先级，并不是通用答案。
打开 App 后看到消息，不代表推送刚刚到
回到开头的场景。用户打开应用后，列表多了几条内容，至少有几种可能。
应用可能刚刚主动向服务器查询了未读消息，也可能恢复了自己的连接，补取断开期间的数据。还有一种情况是消息早已存到本地，只是没有在通知栏提醒，进入页面时才被读出来。
单凭屏幕表现，很难判断是哪条路径起了作用。
列表上的"十分钟前"也未必是设备接收时间。它可能表示发送时间或服务端创建时间，不能拿它直接计算推送延迟。
排查时应保留消息标识，并区分这次内容来自推送、前台补取还是本地读取。没有来源记录，就容易把前台同步的成功，当成后台推送链路没有问题的证据。
已经收到，也可能没有响
"没有通知""没有声音"和"聊天列表没有新内容"，最好分开问。
通知权限、应用的通知总开关、某类通知的渠道设置，以及免打扰等条件，都可能影响提醒的展示方式。Android 的通知渠道允许用户分别控制不同类别通知的行为，应用不能假定自己最初设定的提醒方式始终有效。
如果内容已经正常进入本地消息列表，只是某个通知渠道被关闭，继续增加重连次数并不能修复这个问题。
也不能反过来，看到没有横幅就认为消息没到。用户可能选择静默提醒，锁屏还可能隐藏正文。应用应该尊重这些选择，而不是为了显得"及时"强行绕过设置。
测试时，把后台状态和网络条件分开
第一轮可以先保持网络正常，分别观察前台、普通后台、锁屏，以及明确确认进入的受控待机状态。确认差异后，再给相同状态叠加弱网。
每条测试消息使用可关联的标识，尽量记录业务服务器保存、推送平台受理、设备侧接收、详情拉取和通知发布的事件。某些节点拿不到数据，就标记为未知，别把缺失记录当成"这一阶段没有耗时"。
设备与服务器的时钟也可能不同。未经对齐的时间戳不能直接相减；屏幕录制能说明何时看到了内容，却未必能说明数据何时到达。
还有一个工具边界：只对目标 App 施加弱网，不一定限制了它的推送通道。有些通道由系统或独立服务维护，流量不归目标应用直接持有。
这意味着一次测试可能只影响"收到推送后的详情拉取"，而没有影响推送本身。需要核对实际被处理的流量范围，不能因为打开了弱网工具，就认为整条消息链路都经过了相同损伤。
测试工具自身也可能改变观察环境。常亮屏幕、连接充电、运行某些调试服务，都值得记录；在受控待机测试之外，还应补充更接近日常使用的真机观察。
不要只留下"退出后再打开就好了"
一份有用的结论可以很具体：平台已受理，但缺少设备接收证据；或者设备及时收到提醒，后续详情拉取在弱网下失败；又或者内容正常到达，通知渠道处于关闭状态。
对应的处理也不同。选择适合目标设备环境的推送方案、减少展示对额外请求的依赖、保留合理的前台补取，都有各自用途。让用户把省电和后台限制全部关闭，既不适合当默认方案，也不能替代问题定位。
前台补取之后，还要看迟到内容是否被正确处理。过期的状态提醒不该像刚发生的一样重新打扰用户，重复到达的同一条消息也不该变成两条。
下次用户说"打开 App 才来消息"，先确认他指的是通知栏，还是应用里的内容列表。把这两件事问清楚，再沿着那条消息的记录往前找，通常能少绕不少路。（文章含AI辅助内容）