redis.newclient初始化必须显式配置poolsize（20–50）、minidleconns（≥5）、ping验证、环境变量读地址、所有操作带context超时、键加服务前缀、序列化统一用json，否则高并发下易触发连接池超时或缓存异常。
直接用 redis.NewClient 初始化就开干，90% 的线上缓存故障会在压测或上线后集中爆发——连接池没调、超时没设、键没前缀、序列化不一致，全在初始化阶段埋雷。
redis.NewClient 必须显式配 PoolSize 和 Ping 验证
默认 PoolSize=10、MinIdleConns=0，高并发下不是慢，是排队卡死。现象是 redis: connection pool timeout，但 Redis 本身完全健康。
-
PoolSize设为 20–50：低于 20 容易请求排队；高于 50 可能打满 Redis 的maxclients（单实例建议 ≤5000） -
MinIdleConns必须 ≥5：防 SLB/NAT 网关静默断连，否则第一个请求必重连失败 - 初始化后立刻跑
rdb.Ping(ctx).Err()：别等第一个Get才暴露地址错/密码错/网络不通 - 地址必须从环境变量（如
REDIS_ADDR）或配置中心读，硬编码"localhost:6379"在容器环境必炸
所有 Redis 操作必须带 context.WithTimeout
用 context.Background() 调 client.Get 或 client.Set，等于把 goroutine 生死交给 Redis 响应时间——它卡 2 秒，你的 handler 就卡 2 秒，监控只看到 goroutine 数暴涨、QPS 断崖下跌。
- HTTP handler 中统一用：
ctx, cancel := context.WithTimeout(r.Context(), 300*time.Millisecond) - 写操作（
Set、Del、SET key val NX PX 1000）同样要超时，分布式锁写不进还不超时，后续请求全空等 - 绝不在
init()里声明全局ctx = context.Background()——它没有 cancel 信号，是“永生上下文”
缓存键必须加服务前缀，结构体序列化方式必须全局统一
多个服务共用一个 Redis 实例但没前缀，或同一结构体在不同模块混用 json.Marshal 和 gob.Encode，结果就是缓存读出来 invalid character 或直接 panic，日志里找不到源头。
- 键格式示例：
"user-service:user:123"、"order-service:order:20240501" - 统一用
encoding/json，禁用gob（跨语言/版本不兼容） - 结构体字段必须导出 + 显式
json:"field_name"tag，否则json.Marshal后为空对象
穿透/击穿/雪崩必须在 Go 层兜底，Redis 自身不解决
这三类问题上线后大概率遇到，靠加锁或布隆过滤器容易过度设计。轻量策略更稳：
- 穿透：查 DB 返回空，缓存层存
rdb.Set(ctx, key, "null", 60*time.Second)；业务解包前先判if val == "null" { return nil, nil } - 击穿：用
singleflight.Group包一层Do，同一 key 的并发请求只放行一个去查 DB - 雪崩：TTL 加随机扰动，如
baseTTL + time.Duration(rand.Int63n(int64(2*time.Minute)))；每次生成前用time.Now().UnixNano()做 seed
最常被忽略的其实是连接老化与中间设备静默断连——MaxConnAge 不设或设太长，连接看似活着，实际已被 NAT 网关单向切断，后续请求 hang 住不动。这个点在线上排查时最难定位，得靠主动老化+重连机制兜住。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
