秒杀超卖本质是并发写冲突，需后端协调而非Gin解决；Redis+Lua通过原子脚本实现“读-判-扣-写”一致性，避免ABA问题与分布式失效。
秒杀超卖本质是并发写冲突，Gin本身不解决，得靠后端协调
Gin只是HTTP路由和中间件框架，它不提供库存扣减的原子性保障。所有“Gin防超卖”方案，实际都是在Gin请求处理链路里嵌入外部协调机制。直接在Handler里用if stock > 0 { stock-- }必然超卖——Go的goroutine不是事务，多个请求同时读到相同库存值再各自减一，就是经典ABA问题。
Redis + Lua是性价比最高的排队落地方式
本地锁（sync.Mutex）在多实例部署下完全失效；数据库行锁（SELECT ... FOR UPDATE）在高并发下容易阻塞甚至死锁；而Redis单线程+Lua原子执行，天然适合做分布式计数器和排队信号量。关键不是“用Redis”，而是用EVAL把“读库存→判断→扣减→写回”压进一个Lua脚本里执行。
- 示例Lua脚本：
if redis.call("GET", KEYS[1]) >= tonumber(ARGV[1]) then return redis.call("DECRBY", KEYS[1], ARGV[1]) else return -1 end -
KEYS[1]传商品ID键名，ARGV[1]传扣减数量（通常为1） - Gin Handler中调用：
redisClient.Eval(ctx, luaScript, []string{"stock:1001"}, "1").Result() - 返回
-1即库存不足，直接c.AbortWithStatusJSON(400, gin.H{"error": "sold out"})
用Channel做内存级排队只适用于单机压测，别上生产
有人用chan struct{}做限流队列，看似简单：初始化容量为库存数的buffered channel，每个请求select { case 。但这有三个硬伤：
- channel容量固定，无法动态更新库存（比如运营中途补货）
- goroutine阻塞在channel上会持续占用栈内存，10万并发=10万个goroutine挂起，OOM风险极高
- 多实例部署时，各进程channel互不感知，超卖照旧
它唯一适用场景是本地单元测试或单机模拟，千万别当成线上方案。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
真正要关注的是“排队”和“扣减”的分离时机
用户点击秒杀按钮后，前端应立即禁用按钮并显示“排队中”，而不是等后端返回才响应——这能显著降低重复提交。后端收到请求后，先快速校验用户资格（登录态、限购数）、再进Redis排队队列（如LPUSH wait_queue:1001 user_id），最后由后台goroutine从队列取用户、扣库存、发MQ通知。这样HTTP请求不卡在扣减逻辑里，吞吐量才能撑住。
最容易被忽略的点：Redis队列长度没做上限控制。如果瞬间涌入50万请求，全塞进wait_queue，内存爆掉或Redis OOM，整个服务雪崩。必须加LLEN预检，超阈值直接返回“当前排队人数过多，请稍后再试”。
