加锁必须用 set key value ex seconds nx，value 需唯一（如 uuid），解锁和续期必须用 lua 脚本校验 value，ttl 设为业务 p99×2，长任务需看门狗续期，redlock 多数场景不必要。
加锁必须用 SET key value EX seconds NX，别信单 SetNX
Go 生态里很多教程说“用 rdb.SetNX 就行”，但这是错的——老版本 Redis 不支持在 SetNX 里直接设过期时间，而 Go 客户端（比如 go-redis/v9）的 SetNX(ctx, key, val, ttl) 是靠服务端 SET ... NX EX 命令实现的。如果你连的是 Redis 2.4 或没开 Lua 支持的旧实例，它会 fallback 成两步：先 SETNX，再 EXPIRE，中间一崩溃，锁就永远卡住。
-
value必须是每个 goroutine 独立生成的，比如uuid.NewString()；写死成"1"或复用字符串，解锁时根本分不清是谁的锁 -
EX足够，除非你要毫秒级精度（那就用PX）；但注意 Go 的time.Second别误转成纳秒传给EX，否则锁 1 秒变 10 亿秒 - TTL 建议设为「业务 P99 耗时 × 2」，比如导出接口最长跑 1.2s，就设
2 * time.Second；太短会导致锁提前释放，太长会让故障恢复变慢
解锁必须用 Lua 脚本，GET + DEL 是经典竞态
很多人写完 GET 判断值相等，再调 DEL，结果 A 拿着锁还没删，B 查到过期去抢，A 一删就把 B 刚 set 的锁干掉了——这不是 bug，是必然发生的 race condition。
- 唯一安全解法是原子脚本：
EVAL "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end" 1 lock:key abc123 - Go 里用
redis.NewScript(unlockScript).Run(ctx, rdb, []string{key}, clientID)，返回int64，非1就代表解锁失败，得记录日志或告警 - 别把脚本拼在代码里，用
embed.FS或 const 管理，方便审计和灰度上线时热替换
长任务必须配看门狗续期，EXPIRE 单独调等于裸奔
业务执行时间不确定，锁又不能不设 TTL（否则主从切换后锁丢失），这矛盾只能靠续期解。但乱续期更危险：A 续了 B 的锁，B 还以为自己拿着锁在改数据。
- 续期也得用 Lua 校验：
if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("EXPIRE", KEYS[1], ARGV[2]) else return 0 end - 续期间隔建议为 TTL / 3，比如 TTL=2s，就每 600ms 续一次；太密增加 Redis 压力，太疏容易掉锁
- 业务函数 return 前必须显式 stop 续期 goroutine，否则锁释放了，后台还在不停续——变成“幽灵续期”
Redlock 不是银弹，多数场景单实例+正确实现就够用
Redlock 看起来高大上，但实际落地要连 ≥3 个独立 Redis 实例、校准时钟、处理网络分区、应对幽灵锁……运维成本远超收益。除非你有金融级一致性要求，否则单实例锁只要做到 value 唯一 + Lua 解锁 + 合理 TTL + 续期，已覆盖订单幂等、库存扣减、定时任务防重跑等绝大多数场景。
- 别用
redis.NewClusterClient()或redis.NewFailoverClient()初始化 Redlock，它们内部做转发，破坏“独立实例”前提 - Redlock 的有效时间 = 最小成功 SET 的 TTL − 全程耗时，所以
mutex.Lock()后立刻调mutex.Expiry()拿真实剩余时间，别硬写 sleep - 如果业务里先查 DB 再锁 key，查和锁之间已有脏数据进来——分布式锁管不了这个，得靠数据库唯一索引或乐观锁兜底
最常被忽略的一点：锁不是事务。它只保证“同一时刻一个客户端能进临界区”，不保证操作成功、不兜底 panic、不解决跨服务协同。锁内发生 panic 且没 defer unlock，锁靠超时释放，但没人知道它啥时候丢的。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
