Go项目Redis缓存问题八成出在初始化、超时控制和连接复用：必须显式配置PoolSize（20–50）、MinIdleConns（≥5）、MaxConnAge（30分钟），初始化后调rdb.Ping验证连通性；所有操作须用context.WithTimeout而非context.Background()；键要加前缀，结构体序列化方式需统一。
Go 项目里 Redis 缓存配不好，不是慢就是崩——问题八成出在初始化、超时控制和连接复用这三处，而不是业务逻辑写得不对。
redis.NewClient 不能直接用，必须显式配置 PoolSize 和 MinIdleConns
默认 PoolSize 是 10，MinIdleConns 是 0，高并发下极易排队阻塞或空闲连接断连后重建失败。线上服务一压就报 redis: connection pool timeout，基本就是这个原因。
-
PoolSize建议设为 20–50：低于 20 容易排队；高于 50 可能打满 Redis 的maxclients（默认 10000，但单实例通常建议 ≤5000 连接） -
MinIdleConns必须 ≥5：防止网络设备（如 SLB、NAT 网关）静默关闭空闲连接，导致首次请求时重连失败 -
MaxConnAge设为30 * time.Minute：强制老化连接，避免长连接因中间设备超时被单向断开 - 别漏掉
rdb.Ping(ctx).Err()：初始化后立刻验证连通性，否则第一个Get才暴露错误，排查成本翻倍
所有 Redis 操作必须带 context.WithTimeout，不能用 context.Background()
context.Background() 在 HTTP handler 或 goroutine 中直接传给 client.Get 或 client.Set，等于放弃超时控制。Redis 响应慢 2 秒，goroutine 就卡死 2 秒，监控看到的是 CPU 正常、QPS 下跌、goroutine 数持续上涨。
- HTTP handler 中统一用
ctx, cancel := context.WithTimeout(r.Context(), 300*time.Millisecond)：继承 request 生命周期，同时限制缓存层耗时 - 写操作（如
Set、Del、分布式锁SET key val NX PX 1000）同样要超时：锁写入失败不超时，会导致后续请求永久等待 - 别在
init()里声明全局ctx = context.Background()：它不是“默认上下文”，而是“无终止信号的上下文”
缓存键没前缀、结构体序列化不一致，是线上数据错乱的隐形推手
多个服务共用一个 Redis 实例却没加命名空间前缀，或不同版本 Go 代码对同一结构体用 json.Marshal / gob.Encode 混用，缓存读出来是乱码或 panic，日志里只显示 invalid character 或 EOF。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
立即学习“go语言免费学习笔记（深入）”；
- 所有键强制加前缀，例如
"user:" + userID、"product:detail:" + id；微服务场景下建议加服务名前缀，如"svc-order:user:123" - 结构体存 Redis 必须固定序列化方式：全项目统一用
json.Marshal/Unmarshal，且字段 tag 显式声明（如json:"id,string"），避免 int64 被转成 float64 - 缓存空值防穿透时，写
"null"字符串而非nil，读取后判if val == "null" { return nil, nil }，否则业务层容易 panic
缓存雪崩和击穿必须在 Go 层兜底，Redis 自己不解决
Redis 不管你 key 是不是同一秒过期，也不管是不是 1000 个请求同时查一个刚过期的热点 key。这些策略必须由 Go 业务代码实现，否则 DB 直接被打挂。
- 雪崩防护：TTL 加随机扰动，例如
baseTTL + time.Duration(rand.Int63n(int64(2*time.Minute)))；注意每次调用前用rand.Seed(time.Now().UnixNano())，别用全局rand.Seed() - 击穿防护：用
singleflight.Group包一层Do，同一 key 的并发请求只放行一个去查 DB，其余等待结果 - 穿透防护：DB 查不到时，
client.Set(ctx, key, "null", 60*time.Second)，简单有效，比布隆过滤器更轻量、更可控
最易被忽略的是：连接池参数和 context 超时必须在初始化阶段一次性配齐，而不是等压测出问题再补。很多团队把这步放在“后续优化”里，结果上线后第一波流量就触发连接风暴或 goroutine 泄漏。
