用 redis.Decr 原子扣库存，避免 SQL 分步校验导致超卖；配合 SETNX 实现幂等下单；设置 key 过期时间并及时 Incr 回滚；禁用本地缓存与数据库唯一索引防重。用 redis.Decr 原子扣库存，别写两行 SQL高并发下超卖或秒杀失败，八成卡在库存校验逻辑上。最典型错误是先 SELECT stock FROM seckill_goods WHERE id=?，再判断是否 >0，最后 UPDATE SET stock=stock-1——中间任何并发请求都能绕过检查，因为数据库没锁住“读-判-改”整条链。正确做法是把判断和扣减压进一条原子操作：redis.Decr 天然支持：它返回扣减后的值，你只需检查是否 ≥ 0 就能确认成功与否。Decr 是线程安全的，不依赖客户端加锁，也不受 Go 协程调度影响务必设置 key 过期时间，比如 SETEX seckill:stock:123 3600 100，避免场次结束库存残留扣减失败时要立刻 Incr 回滚，否则 panic 或网络中断会导致库存永久变负用 SETNX 防重复下单，别信前端 disabled 或 session用户刷新页面、F5 重发、脚本模拟，都可能让同一个账号多次提交。只校验登录态或靠前端按钮置灰毫无意义。必须在服务端做幂等控制，推荐用 Redis SETNX 打唯一标记：立即学习“go语言免费学习笔记（深入）”；key 设计为 seckill:order:123:user456（场次 ID + 用户 ID）value 可存随机 token 或时间戳，过期时间略长于支付超时（比如 15 分钟）只有 SETNX 返回 1 才允许走后续流程；返回 0 直接返回 “您已参与本场秒杀”不能用本地 map 或 sync.Map，分布式部署下无效；也不能用 MySQL 唯一索引替代——写库太慢，扛不住瞬时洪峰用带缓冲的 channel 控制 goroutine 并发度写个 for i := 0; i 看似简单，实际极易触发系统级问题：文件描述符耗尽、GC 频繁、Redis 连接池被打爆、甚至进程被 OOM killer 杀掉。 Trenz AI驱动的社交电商营销平台，专为TikTok Shop设计