redsync 初始化必须传入实现 redis.cmdable 接口的客户端（如 redis.client 或 redis.clusterclient），不可用 redis.universalclient；须全局复用单个 *redsync.redsync 实例，lock/unlock 必须配对使用 context 并显式 defer unlock。
Redsync 初始化必须传入 redis.Client 而非 *redis.Client
Redsync 的 NewClient 接口只接受 redis.Cmdable 类型，常见错误是直接传 *redis.Client 却忽略它其实已实现该接口——但问题常出在初始化方式不对。比如用 redis.NewClient() 返回的是 *redis.Client，可直接传入；但若你用了 redis.NewClusterClient()，返回的 *redis.ClusterClient 也实现了 Cmdable，同样可用。别手动取地址或做类型断言。
容易踩的坑：
- 误以为要传
redis.Client值类型（Go 中redis.Client是结构体，不可直接实例化） - 用错客户端：Redsync 不支持
redis.UniversalClient，会 panic 报panic: interface conversion: redis.UniversalClient is not redis.Cmdable - 未检查连接健康状态，锁操作前没调用
client.Ping(ctx).Err()，导致锁获取超时或静默失败
创建 Redsync 实例时需复用同一 client，避免并发竞争
Redsync 内部使用 client 发起 EVAL 和 DEL 命令，若每个锁都新建一个 redsync.Client，会共享底层 redis 连接池但各自维护独立的随机数生成器和超时逻辑，容易造成锁续期冲突或误释放。正确做法是全局复用一个 *redsync.Redsync 实例。
实操建议：
- 在服务启动时初始化一次：
rs := redsync.New(client)，注入到 handler 或 service 层 - 不要在每次加锁前 new 一个
redsync.New(...)，否则SetExpiry、SetTries等配置无法统一生效 - 若服务连接多个 Redis 集群（如读写分离），需为每个集群单独建
redsync.Redsync，不能混用 client
Lock 方法必须显式指定 context 并设 timeout，否则可能永久阻塞
mutex.Lock() 默认不设超时，底层会不断重试直到成功或被 cancel。微服务中绝不能依赖“最终成功”，必须控制等待上限。典型错误是传 context.Background() 或未设 context.WithTimeout。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
关键参数说明：
-
expiry（锁自动过期时间）：建议 ≥ 单次业务处理最大耗时 × 2，例如业务最长 5s，则设10 * time.Second -
tries（最大重试次数）：Redsync 默认 32 次，但配合retryDelay更可控；建议设redsync.WithTries(16)+redsync.WithRetryDelay(50 * time.Millisecond) - 务必用
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)，并在 defer 中调用cancel()
示例片段：
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()
mutex := rs.NewMutex("order:12345", redsync.WithExpiry(10*time.Second))
if err := mutex.Lock(ctx); err != nil {
return err // 包括 redsync.ErrFailed、context.DeadlineExceeded 等
}
Unlock 必须在 defer 中调用且检查 err，否则锁残留风险极高
Redsync 的 Unlock() 不是幂等操作，失败后不会自动重试，也不会释放锁。如果业务 panic 或提前 return，又没 defer unlock，该 key 会在 Redis 中残留至 expiry 过期——这在高并发下单场景下极易引发数据不一致。
安全写法只有这一种：
- 必须在
Lock()成功后立即 deferUnlock()，且传入同一个 ctx（哪怕只是context.Background()） - 必须检查
Unlock()返回的 error：常见redsync.ErrNotLocked表示锁已被其他节点释放，可忽略；但redis.Nil或网络错误需记录告警 - 禁止在 Unlock 前 return 或 panic —— 若业务逻辑可能 panic，用
recover()+ 显式 unlock
容易被忽略的细节：即使 Lock() 失败，也不该调用 Unlock()，否则会报 redsync.ErrNotLocked；只有 Lock() 返回 nil 后才可 unlock。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
