SpringBoot + 最大努力通知 + 回查机制：第三方支付回调的终极一致性保障
一、支付回调的那些坑，你踩过几个？ 上周，公司的电商系统又因为支付回调出问题了。 用户在小程序上下单支付，明明钱已经扣了，订单却一直显示"待支付"。客服电话被打爆，运营同学急得团团转，技术群里更是炸开了锅。 排查了半天，发现是微信支付的回调通知因为网络波动没收到，而我们的系统又没有做兜底处理。 这样的场景，作为后端开发的你，是不是似曾相识？ 二、为什么支付回调这么难搞？ 第三方支付（微信支付、支付宝等）的回调机制，本质上是一种异步通知。支付平台在用户完成支付后，会向我们的系统发送一个HTTP请求，告知支付结果。 但这个过程中，可能会遇到各种问题： 网络抖动：回调请求在传输过程中丢失 系统故障：我们的回调接口临时不可用 处理超时：回调处理逻辑执行时间过长，支付平台认为通知失败 重复通知：支付平台重试机制导致同一笔支付被通知多次 这些问题，都会导致我们的系统无法及时、准确地处理支付结果，从而影响用户体验，甚至造成资金风险。 三、最终一致性：支付系统的底线 对于支付系统来说，最终一致性是必须要保证的。也就是说，无论中间过程多么曲折，最终用户的支付状态和订单状态必须是一致的。 如何实现这个....
