go-redis/v8是当前最稳定、社区支持最充分的redis客户端，生产环境建议优先使用；必须显式配置poolsize（建议20–50）和minidleconns（如5），所有操作须带context.withtimeout，key类型与命令需严格匹配，并在go层兜底缓存穿透、击穿、雪崩问题。
go-redis/v8 是当前最稳定、社区支持最充分的 Redis 客户端，redis/v9 已发布但部分中间件（如 goredis 兼容层、某些监控 SDK）尚未完全适配；生产环境建议优先用 v8，除非明确需 v9 的新特性（如更细粒度的连接池指标暴露）。
redis.NewClient() 必须显式配置 PoolSize 和 MinIdleConns
默认 PoolSize: 10 在压测或突发流量下极易打满，表现为请求延迟陡增、redis: connection pool timeout 错误频发，而非直接报错。连接池不是“够用就行”，而是要匹配业务并发模型：
-
PoolSize建议设为 20–50：HTTP 服务按 QPS × 平均 RT（秒）粗估，比如 1000 QPS × 0.1s = 100 并发连接需求，PoolSize 至少设 30 起步 -
MinIdleConns必须设（如 5），否则冷启动时每个新请求都触发建连，首屏加载慢、日志里一堆redis: dial tcp日志 - 别信“连接池自动扩容”——
go-redis不会动态扩缩，超限就排队，不是失败
所有操作必须带 context.WithTimeout
用 context.Background() 或不设超时调 rdb.Get()，一旦 Redis 响应慢或网络抖动，goroutine 就卡死，runtime.NumGoroutine() 持续上涨，而错误日志里只看到模糊的 context deadline exceeded，根本看不出是 Redis 拖垮的。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- HTTP handler 中统一用
ctx, cancel := context.WithTimeout(r.Context(), 300*time.Millisecond)，300ms 是缓存场景合理上限 - 写操作（
Set、Incr）同样要超时，尤其分布式锁逻辑里，超时缺失会导致锁假死 - 别在包级变量里提前声明
ctx = context.Background()——它没有取消能力，也不是“默认上下文”
Key 设计和类型误用是 90% 缓存故障的根源
本地调试时只看 Go 日志里的 val, err := rdb.Get(ctx, "user:1001").Result() 返回值，掩盖了真实问题。终端执行 redis-cli -p 6379 后手动查，才能暴露本质：
-
TYPE user:1001确认是不是string；若返回hash却用Get()，会报WRONGTYPE Operation against a key holding the wrong kind of value -
TTL user:1001查是否真有过期时间；很多“缓存没生效”其实是 TTL 设成 0 或负数，Redis 当即删掉 key - 结构体存 JSON 时，确保
json.Marshal()不 panic（字段没加json:tag）、反序列化时类型对得上，否则Get()成功但解包失败
缓存穿透/击穿/雪崩不能靠 Redis 自身解决
Redis 不管这三类问题，必须在 Go 层兜底。过度设计（如全量布隆过滤器）不如轻量手段稳：
- 穿透：查 DB 为空时，
rdb.Set(ctx, key, "null", 60*time.Second).Err()，后续读到"null"直接 return nil - 击穿：热点 key 过期瞬间大量请求打穿 DB，用
singleflight.Group.Do(key, fn)包一层，同一 key 并发只放行一个去查 DB - 雪崩：避免所有 key 同一时刻过期，TTL 加随机扰动：
baseTTL + time.Duration(rand.Int63n(int64(2*time.Minute)))，每次生成前用time.Now().UnixNano()做 seed
真正难的不是写几行 Set 和 Get，而是把连接池参数、context 超时、key 类型校验、空值缓存、并发控制这些点全部串起来，在高并发下不掉链子。线上出问题，往往不是某一行代码错了，而是初始化那一段被跳过的配置漏掉了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
