微信支付回调重复开通会员？Node.js 用 Redis 幂等锁和 MongoDB 状态机兜底

前几天给小程序接微信支付，遇到一个很典型的坑：用户支付成功后，会员被开通了两次。第一反应是前端重复请求，查日志后发现是支付回调在短时间内来了多次。微信回调会重试，网关也可能重试，所以后端绝不能默认“只收到一次”。

回调先当不可信输入处理

第一步肯定是验签，确认请求确实来自微信支付；再校验订单号、金额、支付状态是否与本地一致。这里以官方文档为准，不同接口和证书配置细节别凭记忆写。但验签只能挡住假回调，挡不住真回调重复到达，所以还需要幂等。

Redis 幂等锁：同一单先抢一次处理权

const key = `pay:notify:${orderId}`;
const locked = await redis.set(key, '1', 'PX', 300000, 'NX');
if (!locked) return ack();
const order = await Order.findOneAndUpdate(
  { orderId, status: 'PAID_PENDING' },
  { status: 'FULFILLING' }
);
if (!order) return ack();
await grantVip(order);
await Order.updateOne({ orderId }, { status: 'FULFILLED' });
return ack();

这里我一开始把 Redis 锁当成最终状态，结果发货失败后锁还在，订单卡住。后来改成：锁只负责短时间防并发，真正状态落在 MongoDB。锁可以设置较短过期时间，或者失败时删除；如果发货耗时较长，要用状态字段标记处理中。

MongoDB 状态机：让订单只能往前走

• 待支付：用户下单但未支付，不能发货。
• 已支付待发货：回调验签通过，金额一致，进入可发货状态。
• 发货中：开始开通会员，避免第二个回调同时处理。
• 已完成：权益发放成功，后续回调直接返回成功。
• 异常：发货失败，等待补偿或人工介入。

状态更新时不要先查再改，最好用条件更新。比如只有 status 是“已支付待发货”时，才允许改成“发货中”。这样即使两个请求同时进来，数据库层也只会让一个成功。对支付这种钱和权益相关的事，宁可多一层约束。

补偿任务：别把回调当唯一救命稻草

还有一种更隐蔽的问题：回调收到了，但发货接口超时。此时不能简单返回失败让微信一直重试，也不能假装成功。我的做法是把异常单标记为异常，并用定时任务扫描“发货中”超过一定时间的订单，重新尝试或告警。涉及资金和用户权益，最终一致比单次成功更重要。

“支付回调的底线不是“收到就处理”，而是“重复收到也不会错”。验签防伪造，幂等防重复，状态机防乱序，补偿任务防遗漏。”