sync.Mutex必须成对调用Lock/Unlock，defer需紧接Lock后；漏解锁、提前return或值类型复制会导致死锁或竞态，读写共享数据须全覆盖加锁。
sync.Mutex 是 Go 里最常用、最轻量的加锁方式，但它不是万能的——用错地方、漏解锁、提前 return，都会立刻引发竞态或死锁。别指望“加了锁就安全”，关键在怎么加、在哪加、怎么放。
sync.Mutex 必须配对调用 Lock/Unlock，且 defer 要紧挨着 Lock
很多人写成这样：
func process(data []int) {
mu.Lock()
if len(data) == 0 {
return // ❌ 没 unlock！
}
defer mu.Unlock() // ✅ 这行根本不会执行
// ...
}结果就是：空切片一进来，锁永远卡住。正确做法只有两种：
- 把
defer mu.Unlock()放在mu.Lock()后立刻执行，哪怕后面有多个 return 分支 - 或者用作用域包住，让 defer 生效范围更小：
{ mu.Lock(); defer mu.Unlock(); /* work */ } - 永远不要在 Lock 后写任何可能 panic 或 return 的逻辑，再 wrap 一层 defer
Redis 分布式锁必须用 SET key value EX seconds NX 原子命令
别信 rdb.SetNX(ctx, key, val, ttl) 看似封装得好——它在旧 Redis（如 2.4）或禁 Lua 的实例上会 fallback 成两步：SETNX + EXPIRE，中间崩溃就永久死锁。
立即学习“go语言免费学习笔记（深入）”；
真正安全的加锁只有一条命令：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
SET lock:order:123 "7f8e9a1b-2c3d-4e5f" EX 30 NX
-
value必须是每个 goroutine 独立生成的 uuid，不能复用字符串或硬编码 -
EX 30表示 30 秒过期，别误把time.Second * 30当纳秒传进去（Go 的 Duration 默认是纳秒） - TTL 推荐设为「业务 P99 × 2」，比如导出接口平均 1.2s，P99 是 1.8s，那就设
EX 4
解锁和续期必须用 Lua 脚本，GET+DEL 是经典竞态
这段代码看似合理，实则危险：
val, _ := rdb.Get(ctx, key).Result()
if val == clientID {
rdb.Del(ctx, key)
}A 查到值匹配，正准备 Del，B 已经抢到了新锁，A 一删就把 B 的锁干掉了——这不是偶发 bug，是必然发生。
唯一安全解法是原子 Lua：
if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end- Go 里必须用
redis.NewScript(unlockScript).Run(ctx, rdb, []string{key}, clientID) - 返回非
1就代表解锁失败，得记日志或告警，不能静默忽略 - 长任务要配看门狗续期，续期脚本也得用 Lua 校验 value，且续期间隔建议为 TTL / 3
文件锁用 gofrs/flock，别碰 syscall.Flock
syscall.Flock 在不同系统行为不一致（Linux 支持共享锁，macOS 不支持），还容易被 fork 继承导致意外释放。生产环境推荐 gofrs/flock：
l, err := flock.NewLock("/tmp/myapp.lock")
if err != nil { /* handle */ }
ok, err := l.TryLock()
if !ok { /* 已被占用 */ }
defer l.Unlock() // 它内部已处理 close 和信号中断- 它自动处理进程退出、kill -9、容器 stop 等异常场景下的锁释放
- 不依赖文件内容，只靠内核级 advisory lock，比自己读写 pid 文件靠谱得多
- 注意：它不是分布式锁，仅限单机多进程互斥
实际项目里，sync.Mutex 和 gofrs/flock 很少出问题，真正掉坑里的几乎全是 Redis 锁——因为它的“正确实现”包含加锁、校验、续期、解锁四个环节，漏一个，整个锁就形同虚设。
