sync.Mutex在Gin中直接使用会失效，因为每个请求运行在独立goroutine中，若锁为局部变量则每次新建、无法互斥；必须定义为全局或结构体成员，且高并发下更推荐Redis原子操作（如Lua脚本）或DB唯一约束兜底。
为什么 sync.Mutex 在 Gin 路由里直接用会失效
因为 Gin 的每个请求都在独立 goroutine 中执行，sync.Mutex 如果定义在函数内或作为局部变量，每次请求都新建一把锁，完全起不到互斥作用。真正要保护的是共享资源（比如库存计数器、数据库优惠券剩余量），锁必须是全局或闭包捕获的同一实例。
- 错误写法：
func handler(c *gin.Context) { var mu sync.Mutex; mu.Lock() ... }—— 每次请求新锁，毫无意义 - 正确做法：把
sync.Mutex或sync.RWMutex定义为包级变量，或封装进结构体中随 handler 一起传递 - 更稳妥的选择是用
sync/atomic操作整型计数器（如atomic.AddInt64(&remain, -1)），避免锁开销，但仅适用于简单减库存场景
Gin 中如何安全地扣减 Redis 优惠券库存
单靠 Go 层锁无法跨进程保证一致性，生产环境必须依赖 Redis 的原子操作。推荐用 EVAL 执行 Lua 脚本，把“读库存→判断是否充足→扣减”三步合为一个原子操作。
- Lua 脚本示例：
if redis.call("GET", KEYS[1]) == "0" then return 0 else redis.call("DECR", KEYS[1]); return 1 end - Gin 中调用：
result, err := rdb.Eval(ctx, luaScript, []string{"coupon:1001:stock"}).Int() - 注意
redis.Conn不是线程安全的，务必使用redis.Client（go-redis 库）的Eval方法，它自动处理连接复用与并发 - 别忘了给 key 设置过期时间（
EXPIRE），避免缓存击穿后大量请求打到 DB
怎么防止用户刷接口重复领同一张优惠券
核心是识别“同一个用户 + 同一张券”的组合操作，不能只靠 IP 或 token，得落到业务身份上。
- 最可靠方式：用 Redis 的
SETNX（或SET key value EX seconds NX）记录user_id:coupon_id已领取标记，设置合理过期时间（比如 24 小时） - 如果用户登录态用 JWT，注意从 token 解析出
user_id要做签名校验，不能直接信任 header 传来的字段 - DB 层仍需唯一索引约束：
UNIQUE INDEX idx_user_coupon (user_id, coupon_id)，作为最终兜底，避免 Redis 故障时数据错乱 - 别忽略幂等性：前端按钮点击后立即置灰 + 后端对重复请求返回
409 Conflict和明确提示（如“您已领取过该优惠券”）
高并发下 Gin 接口响应变慢，是不是锁的问题
不一定。锁只是瓶颈之一，更常见的是 Redis 连接池耗尽、MySQL 连接卡住、或日志/中间件同步写磁盘拖慢吞吐。
- 先看指标：用
pprof抓 CPU 和 goroutine profile，确认是不是大量 goroutine 阻塞在mu.Lock()上 - 检查 Redis 客户端配置：
SetPoolSize(50)是否足够？SetMinIdleConns(10)是否设得太低导致频繁建连？ - DB 层别在事务里做 HTTP 调用或复杂计算；优惠券核销逻辑尽量精简，把非关键步骤（如发 MQ、写审计日志）异步化
- 如果真要锁，优先考虑
sync.RWMutex对读多写少场景（如缓存配置加载），而不是无脑用Mutex
并发控制不是加个锁就万事大吉，得看清锁的粒度、范围和替代方案。Redis 原子操作、DB 唯一约束、前端防重，这三层缺一不可。最容易被忽略的是：Lua 脚本里没做空值判断，或者 SETNX 的过期时间设得比业务流程还短，导致误判失效。
