分布式锁真正要防的是服务卡住、任务重复、数据错乱等静默故障，而非goroutine死锁panic；其三大致命坑是未设过期时间致锁永久残留、del误删他人锁、业务超时后自动过期引发脑裂。
微服务里用分布式锁不是为了“加个锁就完事”，而是防止多个实例同时改同一份数据。但锁本身会成为新瓶颈——超时没设、续期失控、误删别人锁、网络分区后脑裂，这些都会让锁从保护机制变成死锁源头。生产环境里，真正要防的不是 goroutine 间死锁 panic，而是服务卡住、任务重复、数据错乱这类“静默故障”。
flock 跨进程文件锁为什么不会触发 Go runtime deadlock panic
flock 是系统调用级阻塞，内核接管等待逻辑，Go runtime 完全感知不到。所以 unix.Flock(fd, unix.LOCK_EX) 卡住时，程序不会 panic，只会挂起——这比 panic 更危险：监控看不到异常，运维只能手动 kill -9，部署脚本可能 hang 在锁上导致后续 reload 失败。
- 默认阻塞行为掩盖资源争用问题，线上表现为“无响应”而非“失败”
- 必须显式加
unix.LOCK_NB才能立即返回错误，把控制权交还业务层 -
os.O_RDONLY + LOCK_EX在 Linux/macOS 直接报syscall.EBADF，得用os.O_RDWR或os.O_WRONLY - 第三方库
github.com/gofrs/flock真正解决的不是“加锁”，而是进程被SIGKILL后锁残留、NFS 挂载不一致、锁路径混用等半夜被叫醒的问题
Redis 分布式锁的三个致命坑及绕过方式
直接用 SETNX 加锁是典型“看着能跑，上线就翻车”。它缺过期机制、无身份校验、不支持续期，微服务高频调用下极易引发数据不一致。
- 锁没设过期时间 → 进程崩溃后锁永久滞留 → 其他实例永远拿不到锁
- 解锁用
DEL直接删 → A 加锁超时释放，B 获取锁，A 仍执行并删掉 B 的锁 → 误删 - 锁自动过期但业务未完成 → 网络分区下两个节点同时持有锁 → 脑裂重入
- 正确姿势：
SET key token NX PX timeout_ms原子写入；解锁必须用 Lua 脚本校验token再删；续期也得用 Lua 校验后再PEXPIRE -
go-redsync默认不校验 client ID，需手动 patch 或传redsync.WithValue(token)
etcd Mutex 锁的 lease TTL 和 key 命名陷阱
etcd 的 clientv3.Concurrency.NewMutex 不是“加锁即生效”，它靠 session lease + watch 实现，session 过期锁就自动释放——这不是 bug，是设计前提，但容易误用。
- lease TTL 设太短（如 3 秒）→ GC 停顿或调度抖动导致心跳失败 → 锁意外释放 → 脑裂
- lease TTL 设太长（如 60 秒）→ 故障恢复慢 → 业务长时间不可用
- 推荐 10–15 秒，且每次
Mutex.Lock()必须配context.WithTimeout控制持有时间 - key 命名不能硬编码
/lock，得带业务前缀，如/lock/order-svc/order_123456，否则不同服务互相干扰 - 别复用 session：每个 mutex 绑定独立
clientv3.Concurrency.Session，混用会导致心跳冲突和锁漂移
自动续期协程的生命周期管理最容易被忽略
续期不是“起了 goroutine 就万事大吉”。它必须和锁生命周期严格绑定，否则锁已释放，续期还在跑，最终续的是别的请求的锁。
- 续期协程必须在
Mutex.Lock()成功后启动，在Mutex.Unlock()或 context cancel 时主动停止 - 避免“永远续期”：设最大续期次数或总存活时间，防止任务卡死却持续霸占锁
- 续期间隔建议指数退避（10ms → 20ms → 50ms），降低 etcd/redis 集群压力
- 如果业务执行时间不确定，优先用 etcd 的 lease 自动续期能力，而非自己起 goroutine
- 解锁前加
mutex.IsOwned()判断，避免重复释放已过期锁
最常被跳过的一步是：加锁成功后，没做幂等校验。锁只保证“同一时刻只有一个实例在执行”，不保证“执行结果唯一”。网络分区、超时重试、客户端重启都可能导致同个操作被执行多次。真正的安全线，是锁 + 数据库 version 字段 + Redis SETNX 二次确认三者组合。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
