结论是：go微服务中redis缓存的核心在于防御击穿、穿透、雪崩及goroutine阻塞；必须显式配置poolsize（50–100）、三超时参数（如3s）、带deadline的context，空结果缓存需加随机ttl偏移，键须带业务前缀与版本号，并建立缓存-db一致性补偿机制。
直接说结论：在Go微服务中用Redis做缓存，核心不是“能不能存”，而是“怎么避免缓存击穿、穿透、雪崩，同时不让goroutine被阻塞”。
go-redis/v9 初始化时必须设对 PoolSize 和超时参数
默认连接池只有10个连接，高并发下会排队等待，rdb.Get 看似简单，实际可能卡在连接获取环节。超时没设好，一次慢查询会拖垮整个HTTP handler。
-
PoolSize建议设为 50–100（视QPS和Redis实例规格而定），别用默认值 -
DialTimeout、ReadTimeout、WriteTimeout全部显式设置，例如3 * time.Second - 务必调用
rdb.Ping(ctx).Err()验证连通性，否则错误会在首次Set或Get时才暴露 - 别把
context.Background()直接传给客户端方法；每个请求应带带 deadline 的ctx，比如ctx, cancel := context.WithTimeout(r.Context(), 200*time.Millisecond)
缓存空结果时 TTL 必须加随机偏移
不加偏移的固定TTL是雪崩温床。比如所有商品详情缓存都设 10 * time.Minute，整点一过大量请求同时打穿缓存涌向数据库。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
time.Duration(rand.Int63n(60000))给基础TTL加最多1分钟扰动 - 空结果也要缓存，但TTL要更短（如
30 * time.Second），避免长期污染 - 判断空值不能只靠
err == redis.Nil，还要检查反序列化后结构体字段是否全零值（尤其JSON解码后）
批量操作必须用 MGET/MSET，别循环调用 Get/Set
单key逐个查，网络RTT叠加+序列化开销，10个key可能比 MGET 慢3倍以上，且更容易触发连接池争抢。
- 键列表长度超过50时，建议拆成多批（如每批30个），避免单次命令过大超限
-
MGET返回[]interface{}，需手动类型断言或用redis.StringSlice辅助解包 - 如果部分key存在、部分不存在，
MGET对应位置返回nil，不是报错，别误判为失败 - 写入用
MSET而非事务——除非需要原子性保证，否则事务反而增加延迟
Key设计要带业务前缀和版本号
没前缀的key如 "user:123" 在多服务共用一个Redis时极易冲突；没版本号的缓存结构变更后，旧数据无法识别，导致解码panic或逻辑错乱。
- 推荐格式：
"svc:product:v2:id:1001"，其中svc区分服务，v2标识结构版本 - 避免用用户输入直接拼key，防止注入（如
"user:" + userID→"user:" + strings.ReplaceAll(userID, ":", "_")） - 删除缓存时，别只删单个key，考虑关联key（如更新商品时，除了
product:id:1001，还要删product:category:shoes这类聚合key）
最常被跳过的细节是：缓存更新和数据库更新之间的时序没兜底。哪怕用了双写，也得有补偿机制——比如监听binlog或加延时消息队列，否则网络抖动一次，缓存和DB就永久不一致了。
