Redis.Decr 是唯一能扛住瞬时洪峰的库存扣减方式，必须校验返回值：nil 表示 key 不存在，200 表示 DB 排队；CPU>70% 或内存≈90% 说明 channel 超载，需优化而非加机器；Gin 限流必须统一放在中间件。
redis.decr 是唯一能扛住瞬时洪峰的库存扣减方式，写两行 sql 或用 mysql 行锁都撑不住真实秒杀流量。
redis.Decr 必须校验返回值并立刻回滚
DECR 不是“执行扣减”就完事了，它返回的是扣减后的数值。不检查这个值，等于把库存交给运气。
- 返回
redis.Nil：说明 key 不存在，可能是活动未开始或配置漏了，不能 panic，得明确返回错误提示 - 返回值 redis.Incr 回滚，否则网络中断或 panic 会导致库存永久变负
- 返回值 ≥ 0：才是真正的成功，且该值就是剩余库存数，可用于前端展示或风控判断
- 别用 Lua 脚本封装 “GET + DECR”，这破坏原子性；正确脚本只做 DECR 并返回新值，由 Go 层统一校验
幂等下单必须用 SETNX，禁用本地缓存和数据库唯一索引
用户刷新、F5、脚本重放，会让同一个账号在毫秒内发多次请求。前端 disabled、JWT claim 标记、session 状态，全无效。
- key 必须设计为
seckill:order:{goodsID}:{userID}，含业务维度，避免跨场次污染 - value 存毫秒时间戳或随机 token，过期时间设为支付超时 + 30s（比如 15 分钟）
-
redis.SetNX返回false就直接返回 “您已参与本场秒杀”，不走任何后续逻辑 - 不能用
sync.Map或本地 map：多实例部署下完全失效；也不能依赖 MySQL 唯一索引防重：写库太慢，洪峰一来 DB 直接排队甚至挂掉
channel 限流容量不是经验值，而是压测出来的生死线
make(chan struct{}, 100) 这个 100 不是拍脑袋定的，它直接决定 Redis 延迟、MySQL 排队、机器内存水位是否越界。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 压测时盯紧
Redis INFO commandstats中cmdstat_decr的 p99 延迟，超过 5ms 就得缩容 - 观察 MySQL 的
SHOW STATUS LIKE 'Threads_running'，持续 > 200 说明 DB 已开始排队 - CPU 长期 > 70% 或内存使用率逼近 90%，不是加机器，而是 channel 已超载，再撑下去会触发 OOM killer
- 如果用了 Gin，限流逻辑必须放在中间件里统一处理，而不是每个 handler 自己写一套
和 <code>defer func(){
异步落单不是优化，是防止 503 的底线
秒杀成功的那一刻，只要 redis.Decr 返回 ≥ 0、订单号生成完成，就必须立刻 HTTP 响应。后面所有操作——写 MySQL、发 MQ、更新销量统计——全扔进异步队列。
立即学习“go语言免费学习笔记（深入）”；
- goroutine 卡住不归还
chan令牌，新请求直接 503；sync.WaitGroup只管收尾，不释放令牌，起不到限流作用 - 异步任务失败必须有重试 + 死信兜底，但重试不能拖慢用户侧响应；这是两层逻辑，不能混在一起
- Redis 库存 key 命名建议用
seckill:stock:{goodsID}，别用sku:{goodsID}:stock—— 后者在集群 slot 分配或 keys 扫描时容易出错 - 真正难的不是写对一行
Decr，而是让channel容量、Redis过期时间、SETNX过期时间、异步队列重试策略这四组参数，在压测中形成闭环咬合
