开赛通知晚到，先分清iPhone通知安排和服务端延迟

收到开赛提醒时，比赛可能已经开始，原因不一定是服务端晚发，也可能是 iPhone 把通知集中送达或暂时延后。排查时要把三个时间分开：赛事通知声称的开赛时间、手机实际显示通知的时间，以及服务端生成或发送通知的时间。前两项通常能在手机上观察，第三项若没有服务端日志，就不能凭手机通知反推出网络延迟。

先检查 iPhone 是否安排了通知送达

iPhone 的“定时摘要”可以把选定应用的通知集中到安排的时间送达；“专注模式”也可能让通知延迟。设置中还可以查看某个应用的通知送达方式。相关选项的名称和位置可能因 iOS 版本、设备而不同，实际排查应以当前手机显示的设置为准。可参考 Apple 对通知安排的说明：在 iPhone 上更改通知设置。

检查时只记录与通知有关的项目：该应用是否允许通知、通知是否被纳入定时摘要、当前是否启用了可能影响送达的专注模式，以及锁定屏幕、通知中心或横幅中的显示方式。这里的目标是确认手机端是否存在“收到后暂不立即显眼呈现”的安排，而不是证明应用服务器一定按时发送。

两次明确标注为虚构的手动观察

虚构观察一：假设某 iPhone 在 18时00分 前检查设置，发现“赛事提醒”被加入定时摘要，摘要时间为 18时30分。当天通知在 18时31分 发出声音，通知内容声称比赛开赛时间是 18时00分。这个记录支持“手机端可能按摘要安排延后呈现”的解释，但仍不能说明服务端何时生成、何时发送，也不能单凭此计算网络延迟。

虚构观察二：假设关闭定时摘要后，只保留其他通知设置不变，再观察下一场提醒。手机在 19时02分 弹出通知，通知内容声称比赛开赛时间是 19时00分。此时可把两次观察列成“开赛时间—实际弹出时间—相关设置”，比较设置变化前后的差异。一次只改一个通知设置，才能减少把结果归因于错误因素的可能；这仍然只是设备端观察，不是服务端发送记录。

如果通知内容同时显示了服务端发送时间，并且两端时钟可比较，才可以进一步计算发送到显示的时间差。例如发送时间为 17时58分、手机显示时间为 18时01分，时间差为 3 分钟。它可能包含服务端排队、推送投递和设备呈现等环节，不能单独称为网络传输耗时。但若只知道通知在 18时01分 出现、内容写着“18时00分 开赛”，只能算出“手机显示时间比通知声称的开赛时间晚 1 分钟”，不能把这 1 分钟称为网络延迟，因为通知可能在开赛前已由服务端发出，也可能内容本身后来才生成。

没弹窗与应用没收到通知不是一回事

“手机没有弹窗”只说明你没有在预期位置看到提醒，可能涉及通知权限、定时摘要、专注模式、显示位置或设备当时的状态。它不等于应用服务器没有发送，也不等于应用已经收到后被系统隐藏。

“应用根本没收到通知”则需要更具体的证据，例如应用自身是否有接收记录、服务端是否有投递记录，或开发方能否提供对应时间点的日志。仅凭 iPhone 设置显示通知已允许，不能证明服务端正常；反过来，手机没有弹窗，也不能证明服务端一定故障。两类情况应分开记录，避免把设备呈现问题和服务端投递问题混成一个结论。

按一次只改一个设置，形成可复核记录

可以建立一张简短记录表，每次只改变一个通知安排，并保留通知原文或截图。不要同时关闭定时摘要、切换专注模式、重装应用和修改其他系统选项，否则即使下一次通知及时出现，也无法知道是哪项变化产生了影响。

最后还要保留结论边界：即使关闭设备端安排后通知更快，也只能说明系统安排可能参与了延迟，不能证明服务端原本正常；即使设备端设置没有异常，也不能证明服务端准时发送。通知更适合作为提醒线索，不应单独当作实时比赛事实，赛事状态仍应以可核验的实时信息为准。

参考资料

Apple：在 iPhone 上更改通知设置——说明定时摘要、专注模式及应用通知送达设置可能影响通知呈现；具体选项会随系统版本和设备而变化。