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 隔离、错误分类清晰、空值语义明确——少一个环节，缓存策略就变成幻觉。
