Redsync 不是开箱即用的锁，必须配合超时、重试、上下文控制和适配 Redis 部署模式（单机需显式设 quorum=1，集群需用 ClusterClient）才能实现真正互斥，否则易出现伪加锁、续命失败或误删锁等问题。
直接上结论：Redsync 不是拿来即用的“开箱锁”，它必须配合合理的超时、重试、上下文控制和 Redis 部署模式才能在微服务中真正互斥——否则你加的不是锁，是幻觉。
为什么 mutex.Lock() 会返回成功但实际没锁住
常见现象是多个服务实例同时执行临界逻辑，日志里却看不到报错。根本原因是 Redsync 默认使用单节点 Redis 客户端（goredislib.NewClient），而 Lock() 底层走的是 Redlock 算法的「多数派投票」逻辑：它默认要求连接 ≥3 个独立 Redis 节点，并在其中 ≥(N/2+1) 个节点上成功 setnx 才算加锁成功。
如果你只连了一个 Redis 实例（比如本地 localhost:6379），Redsync 仍会尝试按集群逻辑走 quorum 判定，但因节点数=1，它退化为单点行为——此时不校验 quorum，也不做故障转移，**等价于裸调 SET key value NX PX 8000**，完全失去 Redlock 的容错意义。
- 生产必须显式区分部署模式：单机用
goredis/v9+ 设置redsync.WithQuorum(1)；集群用goredis/v9+redis.ClusterClient+ 保持默认 quorum - 检查你的
pool := goredis.NewPool(client)中的client类型：如果是*redis.Client，它只支持单节点；如果是*redis.ClusterClient，才支持多节点自动分片 - 忘记设
WithExpiry或WithTries会导致锁过期时间远短于业务耗时，或重试次数不足直接失败
mutex.Extend() 不是保活神器，用错反而引发误删
很多人以为调一次 Extend() 就能无限续命，实际它只对「当前持有该锁的同一进程」有效，且必须满足：value 匹配（即加锁时生成的随机 token）+ 锁未被其他节点释放 + 还在原 Redis 节点上存活。
立即学习“go语言免费学习笔记（深入）”；
微服务中常见陷阱：
- 用全局变量存
mutex实例，导致并发 goroutine 共享同一个mutex.value，续命时覆盖彼此 token - 业务处理中发生 panic 或 context cancel，没来得及
Extend()，锁提前过期，下游服务趁虚而入 - 没配
WithExpiry(30 * time.Second)，Extend()默认只延 20 秒，而你的 DB 事务平均耗时 25 秒 → 续命失败率高
正确姿势是：把 Extend() 放进单独 goroutine，用 time.Ticker 每 1/3 过期时间触发，且绑定到同一 context 生命周期：
go func(ctx context.Context, mutex *redsync.Mutex) {
ticker := time.NewTicker(mutex.Expiry() / 3)
defer ticker.Stop()
for {
select {
case <-ticker.C:
if ok, err := mutex.Extend(); !ok || err != nil {
// log.Warn("extend failed, lock may be lost")
return
}
case <-ctx.Done():
return
}
}
}(ctx, mutex)解锁时 mutex.Unlock() 返回 !ok 的真实含义
返回 !ok 并不总代表“锁已丢失”，它只表示「当前客户端持有的 value 与 Redis 中存储的不一致」——可能原因包括：
- 锁已被别人抢走并修改了 value（真丢失）
- 你用了不同
genValueFunc初始化两个mutex实例，导致 value 不匹配（典型配置错误） - 网络抖动导致
GET成功但DEL失败，Redis 中 key 仍存在，但 client 认为 unlock 失败
关键点：
- 永远不要在
Unlock()失败后 panic 或重试——它本就不保证幂等；正确做法是记录 warn 日志，然后让业务逻辑自行判断是否继续（比如查 DB 状态兜底） - 避免手动传
genValueFunc：除非你明确需要自定义 token 生成逻辑，否则用默认redsync.DefaultGenValueFunc即可 - 微服务间若共用锁名，必须确保所有服务用同一套 redsync 版本（v4.x）和同一 redis client 驱动（如全用
github.com/redis/go-redis/v9），否则 value 编码/解码行为可能不一致
最易被忽略的一点：Redsync 的 mutex 实例不是线程安全的。你在 Gin handler 里复用一个全局 mutex 变量去锁不同商品 ID，等于拿同一把钥匙开所有门——锁名（mutexName）必须动态构造，且每个锁操作都应新建 rs.NewMutex(mutexName) 实例，否则 value、expiry、quorum 等状态会串扰。
