Go 的 recover 不能用于保护 Redis 业务逻辑，因其仅捕获 panic，而 Redis 操作失败（如超时、key 不存在）均返回 error，属正常流程；应通过 errors.Is 等显式判断 error 类型并降级处理，而非依赖 recover“兜底”。
Go 的 recover 不能保护 Redis 业务逻辑本身——它只负责捕获 panic，而 Redis 操作出错（如连接超时、命令失败、key 不存在）99% 都是正常 error，根本不会触发 panic。
为什么 Redis 操作通常不会触发 panic
Redis 客户端库（如 github.com/go-redis/redis/v9）所有公开方法都返回 error，比如 client.Get(ctx, key).Result() 或 client.Incr(ctx, key).Val()。这些错误是预期行为，不是运行时异常：
- 网络断开 → 返回
redis.Nil或具体连接错误，不是 panic - 命令语法错误（如对 string 执行
HGET）→ 返回redis.Error，不是 panic - 并发写入 map 导致崩溃？那是你代码里自己用了未加锁的全局 map，和 Redis 无关
真正会 panic 的场景极少，比如：
- 传了
nilcontext 给client.Get（部分旧版客户端可能 panic，但 v9 已规避） - 手动调用
panic，比如在回调里写了panic("redis fallback failed") - 切片越界、空指针解引用等与 Redis 无关的代码缺陷
该用 error 处理 Redis 错误，而不是 recover
对 Redis 操作，你应该检查并响应 error，而不是靠 recover“兜底”：
立即学习“go语言免费学习笔记（深入）”；
-
if errors.Is(err, redis.Nil)判断 key 不存在，走默认逻辑 -
if err != nil && !errors.Is(err, context.DeadlineExceeded)才记录告警，超时可降级 - 不要把
client.Set(...).Err()忽略掉，更不要用defer func(){ if r := recover(); r!=nil {...} }()包一层假装安全
示例片段：
val, err := client.Get(ctx, "user:123").Result()
if err == redis.Nil {
// key 不存在，查 DB 或返回默认值
return getDefaultUser(), nil
}
if err != nil {
log.Warn("redis get failed", "key", "user:123", "err", err)
// 可选：降级读 DB，或返回 cached value
return fallbackFromDB(), nil
}
recover 唯一合理的使用位置：goroutine 守护层
如果你在后台启动了一个定期刷新 Redis 缓存的 goroutine，且它内部逻辑复杂（比如嵌套调用、反射、第三方解析器），这时才需要 recover 防止它崩溃导致整个服务失联：
- 必须在 goroutine 内部、
defer中直接调用recover - 不能指望外层函数“统一 recover”，因为 panic 不跨 goroutine 传播
- recover 后应立即 return，不继续操作已可能损坏的资源（如已 close 的
redis.Client）
错误示范（无效）：
// main.go go refreshCache() // 这里没 defer recover，panic 会导致 goroutine 消失，无日志
正确写法：
go func() {
defer func() {
if r := recover(); r != nil {
log.Error("cache refresh panicked", "panic", fmt.Sprintf("%v", r))
}
}()
refreshCache() // 这里出 panic 才能被捕获
}()
容易被忽略的坑：recover 后状态已不可信
哪怕你在 Redis 操作前后加了 defer + recover，一旦发生 panic（比如因并发写 map 导致），recover 成功也绝不意味着 Redis 客户端还可用：
- panic 可能由
client.Close()调用中未处理的 error 引发，recover 后再调client.Get会 panic - 如果 panic 发生在事务中间（
client.TxPipelined），recover 后无法回滚，数据可能不一致 - 日志里看到 “Recovered from panic”，但后续 Redis 请求全失败——因为连接池已被破坏，却没人检查
client.Ping()
真正可靠的防护是：用 error 控制流程 + 显式健康检查 + 降级策略，而不是依赖 recover 掩盖底层问题。
