Gin本身不提供并发控制能力，秒杀场景必须由业务层实现限流、原子扣减和请求排队；其goroutine模型会放大并发竞争，导致超卖。
秒杀场景下 Gin 本身不提供并发控制能力，必须靠业务层实现限流、库存扣减原子性、请求排队等机制；直接依赖 gin.Default() 或裸写 handler 几乎必然超卖。
为什么 Gin 的 goroutine 并发模型反而加剧秒杀超卖
Gin 基于 net/http.Server，每个请求天然跑在独立 goroutine 中 —— 这对普通 API 是优势，但对秒杀是“放大器”：1000 个并发请求瞬间触发 1000 个 goroutine 同时执行库存判断与扣减逻辑。若没加锁或原子操作，if stock > 0 { stock-- } 这类代码在多 goroutine 下必然竞争失败。
- Go 的 goroutine 调度极快，
time.Sleep(1)根本拦不住并发，只是让日志看起来“错开”，库存仍被多次读取为同一值 -
gin.Context是单次请求生命周期对象，不能跨请求共享状态（比如库存计数），也不能靠它做同步 - 中间件如
gin.Logger()或gin.Recovery()不参与业务逻辑控制，它们只管日志和 panic 恢复
库存扣减必须用原子操作或分布式锁
本地内存变量（如全局 var stock int64）在多 goroutine 下不安全；哪怕加 sync.Mutex，单机部署下能防超卖，但集群部署时锁失效。真正可用的方案只有两类：
- 数据库行级锁：
UPDATE items SET stock = stock - 1 WHERE id = ? AND stock > 0，检查RowsAffected是否为 1，为 0 则抢购失败 - Redis 原子指令：
DECR stock_key，再用GET判断结果是否 ≥ 0；或更稳妥地用 Lua 脚本封装“读-判-减”三步为原子操作 - 不要用
redis.Incr()或redis.Get()+redis.Set()组合 —— 中间存在竞态窗口，必然超卖
限流要落在网关层或中间件，但不能只靠 Gin
Gin 可以接入限流中间件（如 golang.org/x/time/rate 或第三方 uber-go/ratelimit），但它只对当前实例生效。秒杀场景常见错误是：在 handler 里用 time.Sleep 或简单计数器模拟限流，这既挡不住洪峰，又浪费 goroutine 资源。
- 推荐组合：
nginx做第一层连接数/请求数限制（limit_conn,limit_req），再用 Gin 中间件做 per-user 或 per-IP 的二级令牌桶 - 避免在 handler 内部做耗时限流判断（比如查 Redis + 计算窗口），应提前在中间件中完成，失败直接
c.AbortWithStatusJSON(429, ...) - 注意：
rate.Limiter的Allow()方法不是阻塞式，需配合Wait()或显式判断返回值
排队机制必须异步化，别卡在 HTTP 请求里
用户点击“秒杀”后，如果后端同步处理并长时间等待（比如用 time.After 模拟排队），会迅速耗尽 goroutine 和连接池，导致服务雪崩。
- 正确做法：接收请求后立即返回“已入队”，把用户 ID 和商品 ID 推入消息队列（如 Kafka/RabbitMQ）或 Redis List，由后台 worker 顺序消费
- 前端轮询或 WebSocket 通知结果，而非服务端 hold 住 response
- 若坚持同步响应，必须设硬超时：
c.Request.Context().Done()监听取消，且 handler 内所有 I/O（DB、Redis）都带 context timeout
真正难的不是写几个 DECR 或 rate.Limit，而是把库存校验、限流、排队、失败回滚这几件事在分布式环境下串成一条无竞态、可监控、可降级的链路。Gin 只负责把 HTTP 请求转成 Go 函数调用，剩下的全是你的事。
