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

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

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

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

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