支付回调处理最怕没有幂等保护

支付回调是电商系统里最不能靠运气的一段链路。第三方会重试、网络会抖、人工也可能补触发，如果服务端没有幂等控制，订单状态、支付记录和库存侧影响很容易重复执行。

我在 Feathers + Sequelize 这种组合里，更愿意把幂等键和支付事件表放在最入口。回调先落事件，再根据支付单号或平台回执号做去重，确认是新事件以后才推动订单状态变化。这样即便第三方连续推三次，系统内部也只会有一次有效状态迁移。

真正要小心的，不只是“重复写库”，还有重复发送通知、重复扣减库存、重复触发财务流水。只要这些动作没有统一围绕幂等键收住，问题就不会只停留在数据库层。

支付回调稳定不稳定，很多时候就看有没有把幂等当成第一原则。先把重复事件挡在入口，后面的交易链路才有资格谈可靠。

电商链路里最怕的是边界看起来清楚，状态其实在串味

「支付回调处理最怕没有幂等保护」这种问题在电商系统里几乎都会反复出现，因为订单、购物车、支付、搜索这些模块在业务上彼此相关，但在数据职责上又必须保持克制。前期如果为了开发快而把查询、状态流和补偿动作揉在一起，后面最先受伤的通常不是单个接口，而是排障和补单流程。

落地时优先守住的线

• 先定义谁拥有状态迁移，谁只消费结果，别让多个服务都觉得自己可以改同一份关键状态。
• 把幂等键、事件表和补偿动作放在入口附近，避免重复回调或重复消息把下游一起带乱。
• 搜索、筛选和列表接口优先服务真实业务路径，而不是为了复用表结构把所有能力硬塞进一条查询。