直接用 sync.Mutex 做分布式锁无效，真正可用的高性能方案只有 Redis（原子 SET + Lua 校验）和 etcd（lease + Txn CAS），选型取决于一致性、延迟与运维容忍度。
直接用 sync.Mutex 做分布式锁是无效的——它只在单进程内起作用，多实例部署时完全失效。真正能落地的高性能方案只有两个：Redis（靠原子 SET key value EX seconds NX + Lua 校验）和 etcd（靠 lease + Txn CAS）。选哪个，取决于你对一致性、延迟、运维复杂度的实际容忍边界。
Redis 加锁必须用 SET 命令原子完成，别碰 SETNX + EXPIRE
很多人写 rdb.SetNX(ctx, key, val, ttl) 看似简洁，但底层可能拆成两条命令（尤其旧版客户端），中间崩溃就留死锁。必须强制走原子 SET：
-
SET lock:order:123 "a1b2c3" EX 30 NX：EX 是秒级，PX 是毫秒级，必须显式指定，否则没自动释放机制 - 返回
"OK"才算抢锁成功，nil表示失败，不能只靠 error 判断 - value 必须是全局唯一字符串（推荐
uuid.NewString()），后续所有操作都靠它校验所有权 - 如果用
go-redis/v9，直接调client.Set(ctx, key, value, ttl).Result()即可，它默认走原子 SET
解锁和续期必须用 Lua 脚本，且 value 校验不可省略
DEL key 或 GET + DEL 是典型错误，会导致 A 加的锁被 B 误删。所有关键动作必须收进 Lua，在 Redis 单线程里原子执行：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 解锁脚本：
if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end - 续期脚本（带校验）：
if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("EXPIRE", KEYS[1], ARGV[2]) else return 0 end - 调用时传参顺序必须严格：key 在
KEYS，value 和 TTL 在ARGV，类型要一致（比如 TTL 传整数，Lua 里不能当字符串比） - 返回
int64(0)表示校验失败，此时业务应立即中止，而不是重试——锁已不属于你
etcd 锁更适合强一致性场景，但 lease 生命周期必须手动保活
Redis 主从异步复制可能导致脑裂（两个节点同时认为自己持锁），etcd 的 Raft 日志同步能杜绝这点，代价是延迟稍高、API 更重：
立即学习“go语言免费学习笔记（深入）”；
- 加锁流程：先
client.Grant(ctx, 15)拿 lease ID，再client.Put(ctx, key, clientID, clientv3.WithLease(leaseID)) - 必须用
Txn()做 CAS 校验：OpGet读当前值 +Compare判断是否等于自己的 clientID +OpPut写入，三者打包提交 - lease 不会自动续期，得另起 goroutine 调
client.KeepAliveOnce(ctx, leaseID)，失败要主动Revoke并退出 - key 建议加前缀如
/locks/order/12345，避免和业务 key 冲突；context 超时设太短，网络抖动时容易提前 cancel 导致 lease 过期
最易被忽略的点是锁的「生命周期管理」：Redis 方案里，续期 goroutine 如果没随主业务 cancel 而退出，会持续发无效请求；etcd 方案里，忘了 KeepAlive 或没处理 Revoke 异常，锁就永远卡住。这两个问题在线上压测时往往不暴露，一到流量高峰或网络波动才突然崩。
