defer + recover无法真正保护分布式锁释放，因为recover仅阻止goroutine崩溃，但锁可能已误释放或未释放，导致状态不一致；panic后锁语义不可信，且recover无法区分锁失败与普通错误，真正防护需前置校验、超时控制和结构化错误处理。
不能靠 recover 拦住分布式锁释放失败导致的 panic，必须在加锁/释放前做防御性检查；recover 只能兜底防止 goroutine 崩溃，但锁状态已不可信。
为什么 defer + recover 无法真正保护分布式锁释放
分布式锁（比如基于 Redis 的 SET key value NX PX + Lua 释放）一旦在 unlock() 过程中 panic（如网络超时、Redis 连接断开、Lua 脚本返回非预期值），recover() 确实能阻止 goroutine 终止，但以下问题无法回避：
- 锁可能已被成功释放，但你的业务逻辑误以为还持有——后续重复加锁会出错
- 锁可能根本没释放（比如 Redis 写入失败后 panic），而
recover()后你又没重试或标记异常，导致死锁 - panic 往往源于底层 client 错误（如
redis.Nil被误解为nil指针解引用），recover 后再调用client.Do()可能再次 panic - 你无法从
recover()返回值判断“是锁释放失败”，还是“只是日志写入失败”——二者都可能 panic
真正该加 recover 的位置：goroutine 入口，不是 unlock() 内部
分布式锁常用于异步任务或 HTTP handler 中，典型错误是只在主流程 defer recover，却忘了 spawn 出来的 worker goroutine：
- 错误写法：
go func() { unlock() }()—— 这个 goroutine 没任何 recover，panic 后直接消失，锁残留 - 正确写法：每个可能触发锁操作的 goroutine 都要自己包一层
defer func() { if r := recover(); r != nil { log.Printf("worker panic: %v", r) } }() - HTTP handler 中也需独立防护：
http.HandleFunc("/pay", func(w http.ResponseWriter, r *http.Request) { defer func() { if r := recover(); r != nil { http.Error(w, "internal error", http.StatusInternalServerError) } }() ... }) - 别指望“全局中间件”覆盖所有 goroutine，recover 无跨协程能力
unlock() 前必须做的三件事，比 recover 更关键
recover 是最后一道防线，真正防崩要靠前置控制：
- 检查锁是否真的被当前 goroutine 持有：
if !lock.isValid() { return errors.New("lock not owned") }，避免误释放他人锁 - 设置超时和重试：
ctx, cancel := context.WithTimeout(context.Background(), 500*time.Millisecond)，防止 unlock 卡死阻塞 defer 执行 - 用结构化错误替代 panic：
err := lock.Unlock(ctx)，而不是让 client 在内部 panic；多数成熟 Redis client（如github.com/go-redis/redis/v9）都返回error而非 panic - 若必须调用可能 panic 的旧版 client，先包装：
func safeUnlock(l *Lock) error { defer func() { if r := recover(); r != nil { log.Printf("unlock panic: %v", r) } }(); l.unlock(); return nil }，但注意：这只能保 goroutine 不崩，不保锁语义
recover 后绝对不能做的事
很多团队在 unlock panic 后试图“自动续锁”或“二次释放”，这是高危操作：
- 不要在 recover 分支里调用
lock.Lock()—— 此时锁状态未知，重入可能破坏一致性 - 不要调用
close(ch)或mu.Unlock()，除非这些资源是在同一个 defer 链里注册的（即：defer file.Close() 和 defer func(){recover()}() 必须在同一个函数内） - 不要对 panic 值做类型断言：
r.(error).Error()可能二次 panic；统一用fmt.Sprintf("%v", r)日志 - 不要返回成功信号：
recover()后函数应立即 return，不继续执行业务逻辑，尤其不能写数据库或发消息
最易被忽略的一点：recover 只能让你的 goroutine 不退出，但分布式系统里，客户端可能早已超时重试，此时你“恢复”了，却不知道上游已放弃——锁防护的本质是状态一致性，不是程序不死。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
