Go 与 Redis 在微服务缓存层必须对齐请求模型、错误传播路径和资源生命周期，否则易导致缓存不一致、goroutine 泄漏或连接耗尽；go-redis/v9 所有操作须传 context 控制超时与取消，连接池需按并发量调优，空值与批量操作需严格防护。
Go 与 Redis 在微服务缓存层不是“配在一起就行”，而是必须按请求模型、错误传播路径和资源生命周期对齐，否则容易出现缓存不一致、goroutine 泄漏或连接耗尽。
go-redis/v9 的 context 传递不能省略
几乎所有 Set、Get、MGet 等操作都要求传入 context.Context，这不是装饰，而是控制超时与取消的唯一手段。微服务中一个 HTTP 请求可能携带 context.WithTimeout，若在缓存调用中忽略它，Redis 阻塞会拖垮整个请求链路。
- 错误写法：
rdb.Get(context.Background(), "key").Result()—— 超时由 Redis 客户端默认值（如 5s）硬编码，无法与上游服务 SLA 对齐 - 正确做法：复用 handler 传入的
ctx，例如rdb.Get(ctx, "user:123").Result() - 注意：
context.WithCancel或context.WithDeadline触发后，go-redis会主动中断 pending 请求，避免 goroutine 挂起
连接池配置直接影响高并发稳定性
默认的 PoolSize 是 10，但在微服务每秒数百请求的场景下，这个值常成为瓶颈。连接池不足会导致 redis: connection pool exhausted 错误，且错误不直接暴露在业务日志里，只表现为延迟陡增或超时。
-
PoolSize建议设为预期并发请求数的 1.5–2 倍（如 QPS 300，设为 400–500） -
MinIdleConns应设为PoolSize的 1/4～1/3，防止空闲连接被过早回收 -
MaxConnAge设为 30m 左右，强制轮换老化连接，避免 TCP Keepalive 失效引发的静默断连 - 别忽略
ConnMaxIdleTime和ConnMaxLifetime，它们共同决定连接复用边界
缓存穿透防护必须在 Go 层落地
Redis 本身不拦截非法 key 查询，所谓“空对象缓存”或“布隆过滤器前置”必须由 Go 代码显式实现。靠 Redis TTL 自动清理是不够的——恶意构造的不存在 key 会直接打穿到下游 DB。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
立即学习“go语言免费学习笔记（深入）”；
- 简单方案：对
Get返回redis.Nil的 key，写入cache.Set(ctx, "key:miss", "nil", 60*time.Second) - 进阶方案：用
github.com/yourbasic/bloom在内存维护轻量布隆过滤器，拦截 99% 的非法 key - 关键点：所有缓存读取路径（包括
MGet）都要统一处理redis.Nil，否则漏掉一处就等于没防 - 注意：不要把空值序列化成
null写入 Redis，Go 的json.Marshal(nil)生成的是null字符串，会被误判为有效值
批量操作 MGET/MSET 的 key 数量有隐性限制
MGet 看似能一次捞多个 key，但实际受 Redis 单命令参数长度和网络包大小限制。超过 1000 个 key 时，不仅响应变慢，还可能触发 Redis 的 proto-max-bulk-len 截断或客户端解析失败。
- 建议单次
MGet不超过 500 个 key；更稳妥是拆成每批 100–200 - 若 key 来源是用户输入（如一批订单 ID），务必先去重：
map[string]struct{}过滤重复项，避免MGet返回重复值干扰业务逻辑 -
MSet同样适用该规则，且要注意：如果其中某个 key 设置失败（如类型冲突），整条MSet仍会成功返回，但部分值未写入 —— 必须检查.Err()并做补偿
最易被忽略的其实是上下文取消后的资源清理：哪怕 Get 返回了 redis.Nil，只要 ctx 已 cancel，后续任何基于该 ctx 的操作（包括日志记录、metric 打点）都应立即退出，否则可能卡住 goroutine 直到超时。缓存层的健壮性，不在功能多全，而在每条路径都尊重 context 生命周期。
