直接用c.JSON处理支付回调会丢钱，因为微信、支付宝回调天然重复且不可靠，网络抖动可能触发3–5次相同通知，若未做幂等校验就直接返回成功，会导致重复扣款、重复发货；Gin无内置防重机制，必须在业务层用out_trade_no等唯一键查库或Redis实现幂等，禁用本地内存缓存，推荐Redis SET key value EX 3600 NX原子操作，失败即返回success跳过后续逻辑。
为什么直接用 c.JSON 处理支付回调会丢钱
支付平台（如微信、支付宝）的回调是「重复且不可靠」的：网络抖动可能让同一笔订单触发 3–5 次回调，而 c.JSON(200, ...) 一返回就认为成功，后续重复请求若没做幂等，就会重复扣款或重复发货。Gin 本身不提供回调防重机制，得自己在业务层堵住这个口。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 回调入口第一行必须做「幂等校验」，用支付平台的
out_trade_no或notify_id作为唯一键查数据库或 Redis，已处理则直接c.String(200, "success")返回，不走后续逻辑 - 避免用本地内存（如 map）存已处理 ID——多实例部署时完全失效
- Redis 的
SET key value EX 3600 NX是最轻量可靠的幂等锁，失败即说明已处理过 - 不要在幂等校验前更新订单状态，否则并发下可能写入两次
用 sql.Tx 包裹转账逻辑，但别卡太久
大批量回调意味着高并发写 DB，如果整个事务从查余额、扣减、记流水、改订单状态全包在一个 sql.Tx 里，锁表时间一长，MySQL 的 innodb_row_lock_time_avg 就会飙升，反而拖垮吞吐。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 只把「校验余额 + 扣减用户账户 + 插入资金流水」这三步放进事务，其他如通知 MQ、更新订单状态、发短信等全部挪到事务外异步执行
- 扣减余额用原子 SQL：
UPDATE accounts SET balance = balance - ? WHERE user_id = ? AND balance >= ?，检查RowsAffected是否为 1，为 0 说明余额不足，立刻回滚 - 事务超时设为 3 秒以内（
ctx, _ := context.WithTimeout(r.Context(), 3*time.Second)），超时直接返回失败，由支付平台重试 - 别在事务里调外部 HTTP 接口（比如调风控服务），网络延迟不可控
回调里别用 go func() {}() 启动 goroutine 处理后续逻辑
看似能快速返回，但 Gin 的 c.Request.Context() 在响应写出后会被 cancel，goroutine 里再用这个 ctx 调 DB 或 Redis，大概率拿到 context canceled 错误，导致消息没发、日志没写、状态没更——钱转了但没人知道。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用独立的、带 cancel 控制的 context 启动 goroutine：
go func() { newCtx, _ := context.WithTimeout(context.Background(), 30*time.Second); doAsyncWork(newCtx) }() - 更稳妥的做法是写入消息队列（如 Kafka/RocketMQ），由消费者服务异步处理后续动作，回调接口只负责「落库 + 幂等 + 返回」三件事
- 如果必须用 goroutine，至少加 recover 和错误日志：
defer func() { if r := recover(); r != nil { log.Printf("async panic: %v", r) } }() - 别在 goroutine 里直接用
c对象（如c.GetString），它不是线程安全的
如何让 Gin 回调接口扛住每秒上千次微信通知
微信回调默认每秒最多推 300+ 次（尤其活动期间），Gin 默认配置在高并发下容易被打穿：连接未复用、日志阻塞、中间件耗时叠加，最终表现为大量 502 Bad Gateway 或超时。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 禁用 Gin 内置日志中间件，用结构化日志（如 zap）异步写入，回调路由单独关掉
gin.Logger() - 设置
http.Server.ReadTimeout = 5 * time.Second、WriteTimeout = 10 * time.Second，防慢连接占满 worker - 用
pprof定期看/debug/pprof/goroutine?debug=2，确认没 goroutine 泄漏（常见于未关闭的 HTTP client 连接） - 回调路径用
router.POST("/pay/callback/wechat", wechatCallbackHandler)单独注册，别混在带 JWT 鉴权的路由组里——微信不会带 token
真正难的不是写完逻辑，而是每次上线前用真实 notify 数据压测：模拟 1000 个不同 out_trade_no 并发回调，看 DB 锁等待、Redis 命中率、MQ 积压量——这些数字比代码更诚实。
