用户没有打开 APP，却在手机桌面看到了通知，这依靠的不是 APP 持续运行，而是系统推送通道。它与应用内提醒是两套机制：应用内提醒由 APP 在打开后读取并展示；系统推送则先经过设备所属的推送通道，再由手机系统决定是否展示。因此，同一条业务消息既可以写入站内消息列表，也可以尝试发送系统通知，但两者不能互相替代。
推送通常从业务事件开始。例如订单状态变化后，业务后台生成通知内容，依据用户设置和发送规则判断是否需要推送，再通过第三方平台或厂商通道提交消息。通道根据设备令牌识别目标设备，将消息交给设备系统处理。用户点击通知后，APP 才会打开并跳转到对应页面。设备令牌在这里是路由标识，不等于用户身份；后台需要维护用户与设备的关联，避免消息发到错误的设备上。
这条链路的关键边界是：提交成功不等于用户已看见。通知权限被关闭、通道限制、设备状态变化，都可能影响最终展示。后台记录的“已发送”、通道反馈的“到达”和 APP 记录的“已打开”，含义也不同，不能混作同一个送达率。要判断推送是否有效，应分别观察发送失败、到达和点击打开情况，并检查失败原因。
设计推送功能时，应先确定哪些消息必须保留在应用内，哪些需要额外提醒到桌面，再处理重复发送、频率控制和用户关闭某类通知后的行为。把站内消息作为用户可回查的记录，把系统推送作为提醒入口，才能在通道未触达时，仍让用户打开 APP 后找到重要信息。
