Gin本身不提供分布式锁，因其仅为HTTP路由框架且gin.Context局限于单次请求内存中，无法跨进程/跨机器协调；需借助Redis等外部存储实现，典型方案是SET key value EX seconds NX配合Lua脚本安全释放。
为什么 Gin 本身不提供分布式锁
Gin 是一个 HTTP 路由框架，它不处理跨进程/跨机器的并发协调问题。gin.Context 是单次请求生命周期内的上下文，完全在内存中，无法感知其他实例或节点的状态。所以你不能靠 sync.Mutex 或 gin.Engine 自身实现真正意义上的分布式锁——那只是单机锁，一加负载均衡就失效。
用 Redis 实现最简可行的分布式锁（Redlock 不必要）
多数场景下不需要严格遵循 Redlock 算法。用 Redis 的 SET key value EX seconds NX 就够用：原子性地设置带过期时间的 key，且仅当 key 不存在时成功。失败即表示锁已被占用。
-
value必须是唯一标识（如uuid.NewString()），避免误删别人持有的锁 -
EX时间要明显大于业务最大执行时间（建议至少 ×2），防止锁自动过期后业务还在跑 - 释放锁必须用 Lua 脚本：
if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end，否则可能删错锁 - 不要用
redis.Del()直接删——这是最常见误操作
Gin 中如何安全嵌入锁逻辑
别把锁逻辑塞进中间件里统一拦截——路径参数、查询参数、请求体内容都可能影响锁粒度。应该按业务语义，在 handler 内部显式加锁。
示例：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
func transferHandler(c *gin.Context) {
from := c.Query("from")
to := c.Query("to")
amount := c.Query("amount")
lockKey := "lock:transfer:" + from + ":" + to
lockValue := uuid.NewString()
ok, err := redisClient.Set(ctx, lockKey, lockValue, 10*time.Second).Result()
if err != nil || ok != "OK" {
c.AbortWithStatusJSON(http.StatusConflict, gin.H{"error": "locked"})
return
}
defer func() {
// 注意：这里不能直接用 defer redisClient.Del(...)！
script := redis.NewScript(`if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end`)
script.Do(ctx, redisClient, lockKey, lockValue)
}()
// 执行转账逻辑...
}
容易被忽略的三个细节
很多人写完发现锁“有时失效”，往往栽在这三点：
- Redis 连接没设
ReadTimeout和WriteTimeout，网络抖动导致SET返回超时错误，但实际写入成功 → 后续请求因超时误判为无锁而并发进入 - 没对锁获取失败做退避重试（比如指数退避 + jitter），而是直接返回错误，用户体验差且压测时容易雪崩
- 锁 key 没做标准化（比如没对
from/to排序），transfer:A:B和transfer:B:A被当成两个锁，破坏互斥性
锁不是越重越好，也不是越轻越安全；关键是在具体业务路径上，让 key 唯一、value 可验证、释放可原子、超时可兜底。
