go语言集成redis缓存必须显式配置poolsize(20–50)、minidleconns(≥5)、maxconnage(30分钟)，初始化后调用rdb.ping验证连通性，所有操作须使用context.withtimeout，key需加服务前缀，value统一用json.marshal序列化，集群场景必须用redis.newclusterclient。
redis.NewClient 是起点，但直接调用它不等于缓存就跑起来了。90% 的线上缓存故障，根源不在业务逻辑，而在初始化、超时控制和连接复用这三步没踩准。
redis.NewClient 初始化必须显式配 PoolSize 和 MinIdleConns
默认 PoolSize=10、MinIdleConns=0，高并发下极易排队或空闲连接断连后首请求失败。这不是 Redis 慢，是连接池“没水了”。
-
PoolSize建议设为 20–50：低于 20 容易阻塞；高于 50 可能打满 Redis 的maxclients（单实例建议 ≤5000） -
MinIdleConns必须 ≥5：防 SLB/NAT 网关静默断连，否则第一个请求必重连失败 - 务必调
rdb.Ping(ctx).Err()验证连通性——别等第一次Get才暴露问题 - 地址别硬编码
"localhost:6379"，从环境变量或配置中心读取，微服务部署下这是刚需
所有 Redis 操作必须带 context.WithTimeout
用 context.Background() 或不设超时的 context.TODO() 调 client.Get 或 client.Set，等于把 goroutine 生死交给 Redis 响应时间。它卡 2 秒，你的 handler 就卡 2 秒，监控里只看到 goroutine 数暴涨、QPS 断崖下跌。
- HTTP handler 中统一用：
ctx, cancel := context.WithTimeout(r.Context(), 300*time.Millisecond) - 写操作（
Set、Del、分布式锁）同样要超时，锁写不进还不超时，后续请求全在空等 - 别在
init()里声明全局ctx = context.Background()——它没有 cancel 信号，根本不是“默认”，是“永生”
Key 和 value 处理稍有不慎就引发数据错乱
多个服务共用一个 Redis 实例但 key 没前缀，或同一结构体在不同模块混用 json.Marshal 和 gob.Encode，结果就是缓存读出来 invalid character 或直接 panic，日志里找不到源头。
- key 必须加服务前缀，比如
"user:" + uid，推荐用url.PathEscape或strconv转义，避免注入和冲突 - value 存 struct？先
json.Marshal再存，别直接传 struct 指针给Set——序列化失败会静默丢数据 - TTL 别设成 0：
Set(ctx, key, val, 0)表示“不设置过期”，不是“永不过期”，更不是“过期时间为 0 秒” - 查不到时写空值防穿透，推荐
client.Set(ctx, key, "null", 60*time.Second)，业务层解包时判if val == "null" { return nil, nil }
Redis Cluster 场景下必须用 redis.NewClusterClient
直接用 redis.NewClient 连集群地址，会反复报 MOVED 或 ASK 错误且无法自动重试——这不是配置问题，是协议层面不兼容。Redis Cluster 依赖客户端解析重定向响应并维护 slot 映射，redis.NewClient 完全不处理这些。
-
Addrs必填，类型为[]string，建议填至少 3 个可达节点地址，提升初始拓扑发现成功率 -
Password若集群启用了密码，必须显式设置；""和未设置效果不同——未设置跳过 AUTH，""会发 AUTH 命令并因无密码失败 -
MaxRedirects生产环境建议设为 16，避免环形重定向；低于 8 可能导致 MOVED 后无法到达目标节点 - 创建
redis.ClusterClient实例不等于连接就绪，首次调用命令可能因拓扑未就绪而超时，需预留缓冲
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
