生产环境必须用redis.NewClusterClient或redis.NewFailoverClient，禁用NewClient；需配置PoolSize（并发请求数2–4倍）、Timeout、MaxRetries、MinIdleConns、MaxConnAge，初始化后调Ping验证，所有操作带超时context，键加服务前缀，空值占位+TTL扰动防穿透雪崩。
生产环境别自己从零写分布式缓存——直接用 redis.NewClusterClient 或 redis.NewFailoverClient，配好连接池、超时、空值占位和 TTL 扰动，就是最稳的高性能起点。
redis/go-redis/v9 怎么初始化才不泄漏、不卡死
全局只用一个 *redis.Client 实例，每次请求都 new 会导致连接数爆炸，Redis 很快拒绝新连接。
-
PoolSize设为预期并发请求数的 2–4 倍（最低 10），比如 QPS=100、平均响应 50ms，建议设PoolSize: 20 - 必须调用
rdb.Ping(ctx).Err()验证连接，否则第一次Get()才暴露网络问题 - 所有操作必须传带超时的
context.Context，例如ctx, cancel := context.WithTimeout(r.Context(), 3*time.Second)，禁用context.Background() - 集群用
redis.NewClusterClient()，哨兵用redis.NewFailoverClient()；redis.NewClient()只适合单节点开发环境 - 加
MinIdleConns: 5和MaxConnAge: 30 * time.Minute，防止 SLB 或 NAT 网关静默断连
缓存键设计不当会直接导致线上事故
键名不是拼个字符串就完事。它决定了多服务共用 Redis 时会不会互相覆盖、运维时能不能快速定位来源。
- 强制加服务前缀，例如
"user-service:user:123"，而不是"user:123" - 避免在键里塞动态长字段（如 email、JSON 片段），容易触发 Redis 的 key 大小限制（默认 512MB）或影响 cluster slot 分布
- 敏感字段（如手机号）建议先哈希再拼入键：
fmt.Sprintf("order-service:order:%x", md5.Sum([]byte(phone)))，防止日志/监控中明文泄露 - 所有键统一用 UTF-8 编码，不要混用
gob序列化结果当 key（二进制不可读、无法 debug）
防穿透、击穿、雪崩不是靠 Redis 配置，而是 Go 层逻辑兜底
这三类问题 90% 出在现场没做任何应对，靠 DB 硬扛。它们不是 Redis 配置问题，是 Go 层逻辑缺失。
立即学习“go语言免费学习笔记（深入）”；
- 穿透：对查不到的 key 写空值 + 随机 TTL，例如
client.Set(ctx, key, "null", 2*time.Minute+time.Duration(rand.Intn(60))*time.Second)；固定 TTL 会导致空 key 集中失效 - 击穿：热 key 过期瞬间大量请求打 DB，用
golang.org/x/sync/singleflight合并请求，Do()返回后统一回填缓存 - 雪崩：所有 key 同一时间过期，用错峰策略，比如基础 TTL 加
rand.Intn(120)秒偏移；高频配置项可考虑永不淘汰（但需配合主动刷新机制） - 注意：别在全局
init里初始化rand，要用rand.New(rand.NewSource(time.Now().UnixNano()))每次生成独立实例
一致性哈希扩容时最容易掉进“数据断层”坑
新节点上线 ≠ 立刻可用。如果没做数据迁移或懒加载，它对大部分 key 都是 miss，等效于缓存雪崩。
- 必须用带虚拟节点的实现（建议 100~200 个），否则物理节点少时分布严重不均
- 新节点加入后不能直接对外提供服务：它还没拿到该负责的那部分旧数据，需触发「数据预热」或「懒迁移」
- 懒迁移方式：新节点首次被路由到某个 key 时，先查本地 cache，未命中则去原属节点拉取并写入本地，再返回——但必须加
singleflight.Group防重复拉取 - 最关键的是健康检查：每个
*redis.Client必须单独做周期性Ping()（比如 5 秒一次），失败连续 3 次就标记剔除；否则 TCP 连接未关闭时，一致性哈希仍会把流量打过去，结果卡死或超时
真正难的不是让缓存跑起来，而是让它的行为可预测、故障可收敛、扩缩容时不抖动——这些细节全在 Go 层的封装逻辑里，不在 Redis 配置里。
