微信支付回调这个坑，我踩了两次

说一个技术坑，做过支付对接的应该都踩过：支付回调。

流程是这样的：用户付完钱，微信服务器会主动给你的服务器发一条通知，说"这笔付成了"。你的系统收到通知，才把订单状态改成"已支付"。

坑在哪？这条通知可能会发好几遍。

微信的逻辑是：你收到通知后要在规定格式里回"收到"，它才停。如果你处理得慢、或者回包的格式不对，它就默认你没收到，隔一会儿再发一次，最多发好几次。

我第一次踩这个坑，是有个商城订单重复发了两次货——回调收到两次，发货逻辑跑了两次，仓库打包了两次。

第二次是回调通知到了，但验签没写对——简单说就是没验证"这条消息真是微信发的"。理论上有人伪造一条"支付成功"通知就能不付钱拿货。查文档重写验签，补上了。

后来每次做支付，我都有个固定清单：

1. 回调必须验签——确认消息真是微信发的，再改订单状态
2. 状态变更要幂等——同一个订单收到十次"已支付"，也只能执行一次"改成已支付"
3. 处理结果按格式回包——回对了它才停发
4. 主动对账——每天跑一次"微信说付成了、但系统显示没付"的查漏，防通知丢失

外行看"接个微信支付"是接个接口的事，内行知道真正的工作量全在异常情况上——重复通知、通知丢失、伪造通知，每一种都得有对应处理。

这也是为什么"报 3000 接支付"和"报 8000 接支付"的区别——便宜的那个大概率只写了正常路径。