sync.Mutex在分布式场景下完全失效，因其仅作用于单进程内存，跨节点时互不感知；真正可用的分布式锁需满足互斥性、防死锁（超时）、加锁者释放三大条件。
为什么直接用 sync.Mutex 在分布式场景下完全失效
因为 sync.Mutex 只作用于单进程内存，跨机器、跨实例时互不感知。你在一个节点上加锁，其他节点根本不知道，任务照样并发执行——这不是锁，是幻觉。
真正能用的分布式锁必须满足三个条件：互斥性、防止死锁（有超时）、解铃还须系铃人（只能由加锁者释放）。常见错误是用 Redis 的 SET key value EX 30 NX 加锁但没做原子性释放，结果锁残留导致任务长期阻塞。
- 别手写 Lua 脚本释放锁，除非你确认
GET + DEL是原子的（它不是） - 不要用服务端时间做锁过期判断，各节点时钟不同步会导致提前释放
- Redis 单点故障会直接让锁失效，生产环境至少用 Redis Sentinel 或 Redis Cluster
用 redis/go-redis 实现可重入、带自动续期的锁
官方 go-redis 不自带分布式锁封装，但提供了 SetNX 和 Eval 接口，配合 time.Timer 可以做出健壮实现。关键在「锁标识」必须是随机且唯一（比如 uuid.NewString()），否则 A 加锁后被 B 误删。
自动续期不是可选功能——网络延迟或 GC 暂停都可能让业务处理时间超过锁 TTL，不续期等于锁提前丢失。续期必须检查当前锁是否仍属自己，用 Lua 脚本保证原子性：
if redis.call("get", KEYS[1]) == ARGV[1] then
return redis.call("expire", KEYS[1], ARGV[2])
else
return 0
end
- 加锁时用
client.SetNX(ctx, lockKey, lockValue, ttl)，失败立即返回 - 启动一个后台 goroutine 负责每
ttl/3续期一次，直到任务完成或上下文取消 - 释放锁必须调用
client.Eval(ctx, luaScript, []string{lockKey}, lockValue, newTTL)
etcd 方案比 Redis 更适合强一致场景
如果你的任务不允许任何锁冲突（比如金融扣款），etcd 的租约（Lease）+ 前缀监听机制比 Redis 更可靠。它的 CompareAndSwap（CAS）基于 Raft 日志，天然线性一致，不存在 Redis 主从异步复制导致的锁“双活”问题。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
用 go.etcd.io/etcd/client/v3 时，锁 key 应带租约 ID，并在获取成功后启动心跳保活。注意：etcd 的 Grant 接口返回的是租约 ID，不是 TTL 值；续期要用 KeepAlive 流，不能反复 Grant。
- 加锁本质是
client.Txn(ctx).If(...).Then(client.OpPut(...)).Commit() - 锁 key 建议格式为
/locks/task_name/{instance_id}，便于 debug 时 list 查看 - etcd 连接断开时租约会自动过期，无需手动清理，这点比 Redis 省心
别忽略锁等待策略和降级逻辑
分布式锁不是万能胶。网络抖动时，TryLock 可能卡住几秒甚至超时，这时硬等不如快速失败+告警+人工介入。很多线上事故源于“锁没拿到就 panic”，而不是走备用路径。
建议所有锁调用都带 context deadline，并预设 fallback 行为：比如降级为本地队列暂存、记录到 DB 待重试、或直接返回 “服务繁忙”。不要让锁成为整个链路的单点瓶颈。
- 设置
context.WithTimeout(ctx, 500*time.Millisecond)，比锁 TTL 短得多 - 等待期间可定期
client.Get(ctx, lockKey)查看锁持有者，辅助定位谁在占用 - 日志里必须打上
lockKey和lockValue，否则排查时你连哪个实例加的锁都不知道
最麻烦的永远不是怎么加锁，而是锁失效后怎么恢复状态一致性——比如任务已部分执行、下游已发消息、数据库已写中间态。锁只是工具，真正的难点在补偿与幂等设计。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
