回调通知的完整旅程：从触发到确认经历了什么

回调通知是平台把结果主动送上门的机制。它的完整旅程比「收到一条消息」要长得多，理解每一环，才能明白为什么通知会重复、为什么会迟到、以及接收端应该怎么回应。

从触发到确认的七个环节

平台无法确认「你处理完了」之前，只能以「应答是否正确」为准。网络抖动、处理超时、应答格式不对，都会让平台认为投递失败，于是按间隔重试。所以通知的到达是「至少一次」而不是「恰好一次」，接收端必须按重复消息来设计。

值得强调的是：先处理完再应答，宁可让重试机制兜底，也不要「收到即确认、处理交给运气」。

同一条通知到达三次，业务动作应该只执行一次。以通知里的业务单号作为幂等标识，落库时先查后写，重复消息直接返回成功。这比「祈祷只来一次」可靠得多。

通知负责实时性，查询负责确定性。长时间未收到通知、或通知内容与本地判断不一致时，主动查询给出的是当前权威状态。两条路径都有，状态判断才完整。

一条通知通常不是只带一个结果，而是一组能定位到具体业务的字段：

通知链路上的问题，九成能通过这五层顺序定位，剩下的才是真正的疑难。

通知没有被正确确认时，通常会按一定节奏重复推送。理解这个节奏，才能设计好接收端的处理策略。

接收端的正确姿势是：先确认、再处理。把耗时逻辑放在确认之前，是通知超时的头号原因。

通知解决及时性，查询解决确定性，两者不是替代关系，而是互补关系。

只依赖通知的系统，会在通知链路出问题时集体失明；只依赖查询的系统，会把大量请求浪费在无谓的轮询上。

回到最初的问题：回调通知不是一条消息，而是一条包含触发、投递、确认、重试与兜底的完整链路。把链路上的每一环都当作独立环节对待，处理结果才会稳定。

一句话总结：通知负责快，查询负责准。