Golang错误处理与缓存穿透/击穿_处理Redis返回的Err

redis get 返回 redis.nil 不等于 go 的 nil，需用 Errors.is(err, redis.nil) 判断缓存未命中；误用 err != nil 会导致错误降级；应区分 redis.nil、网络错误与 context 超时，各操作使用独立子 context。

Redis Get 返回 redis.Nil 不等于 Go 的 nil

Go 官方 redis 客户端（如 github.com/redis/go-redis/v9）里，Get 命令查不到 key 时返回的不是 Go 原生 nil，而是 redis.Nil 错误——它是一个预定义的错误值，类型是 error，但不等于 nil。直接用 if err != nil 判断会把「缓存未命中」当成真实错误处理，导致误打日志、触发降级或写空值到缓存。

实操建议：

立即学习“go语言免费学习笔记（深入）”；

• 用 errors.Is(err, redis.Nil) 显式判断缓存未命中，而不是 err == nil 或 err != nil
• 不要在 if err != nil 分支里统一兜底，得先分清是 redis.Nil 还是网络超时、连接断开等真错误
• redis.Nil 是可比较的，但别用 err == redis.Nil —— 它是变量，不是常量；必须用 errors.Is

缓存穿透：查一个根本不存在的 key，反复击穿到 DB

典型场景是恶意刷 ID（比如 /user?id=999999999）、或用户输入非法参数。Redis 没有该 key，返回 redis.Nil，业务层又没做空值缓存或布隆过滤，每次请求都落到 DB。

实操建议：

立即学习“go语言免费学习笔记（深入）”；

• 对确认「永久不存在」的 key（如非法格式 ID），写入一个短 TTL 的空值（例如 SET user:999999999 "" EX 60），避免重复穿透
• 空值内容别用 nil 或 "" 就完事——DB 层可能也返回空，要加标识，比如 {"empty": true, "reason": "invalid_id"}
• 更轻量方案是前置布隆过滤器（Bloom Filter），但注意它有误判率，且需维护一致性；上线前务必压测误判带来的 DB 压力

缓存击穿：热点 key 过期瞬间大量并发请求涌向 DB

比如商品详情页的 key item:123 设置了 5 分钟 TTL，一到期，上百个请求同时发现 Redis 没值，全去查 DB，DB 瞬间被打满。

实操建议：

立即学习“go语言免费学习笔记（深入）”；

• 用「逻辑过期」代替物理过期：value 里嵌入一个 expire_at 字段，Redis key 永不过期；读取时先检查时间戳，过期则异步刷新，不阻塞请求
• 或者用分布式锁（如 SET item:123_lock "1" NX EX 3），只有抢到锁的请求去 DB 加载，其余等待后重读 Redis —— 注意锁失败后必须设重试上限，否则雪崩
• 别依赖 GETSET 或 SETNX 自己手写锁逻辑，容易死锁或漏释放；优先用 redis.NewLock（redlock）或已验证的封装

错误处理链路中混用 ctx 和超时，导致缓存层误判失败

常见错误是给整个 http 请求配了 3s context.WithTimeout，然后在同个 ctx 下串行调 Redis + DB。Redis 耗时 800ms，DB 耗时 2.3s，总超时，但此时 Redis 实际成功了——你却因为 ctx 取消而把 context.Canceled 当成 Redis 故障，可能错误地剔除连接池或切流。

实操建议：

立即学习“go语言免费学习笔记（深入）”；

• Redis 调用必须用独立子 context，例如 redisCtx, _ := context.WithTimeout(ctx, 200*time.Millisecond)，和 DB 的 timeout 分开控制
• 别把 context.DeadlineExceeded 或 context.Canceled 和 Redis 协议错误（如 redis: connection closed）混为一谈；前者是调用方行为，后者才是服务端问题
• 如果用了 redis.HSet 写空值防穿透，记得这个操作也要套自己的短 timeout，不能复用主流程长 timeout，否则空值写不进去，穿透照旧

真正难的不是写对 errors.Is(err, redis.Nil)，而是所有分支里都保持 ctx 隔离、错误分类清晰、空值语义明确——少一个环节，缓存策略就变成幻觉。