直接用redis.Client初始化就上线是90%缓存故障根源；必须显式配置PoolSize（20–50）、MinIdleConns（≥5）、MaxConnAge（30分钟），初始化后调rdb.Ping验证连通性，所有操作用context.WithTimeout而非Background，并统一键前缀、序列化方式与错误处理。
直接用 redis.Client 初始化就上线，90% 的缓存故障由此开始。 不是 Redis 不稳定，而是 Go 微服务里没管好连接、超时、序列化、键空间和错误传播——这些必须在代码层显式控制，不能靠“默认值”或“等出问题再修”。
redis.Client 初始化必须设 PoolSize 和 Ping 验证
微服务启动时若只写 redis.NewClient(&redis.Options{Addr: "redis:6379"})，会沿用默认 PoolSize=10，但实际并发请求远超此数时，redis: connection pool timeout 就频繁出现；更糟的是，不调用 rdb.Ping()，首次 Get() 失败才暴露连接问题，线上已卡顿。
- 根据服务 QPS 设置
PoolSize：100 QPS 建议设为 20–40，别低于 10 - 务必在
init()或启动函数中执行rdb.Ping(ctx).Err()，超时用context.WithTimeout控制（别用context.Background()） - 设置
MinIdleConns=5和MaxConnAge=30*time.Minute，防中间网络设备静默断连
缓存键必须带服务前缀 + 版本号
多个微服务共用一个 Redis 实例时，user:1001 这种裸键极易冲突。更隐蔽的问题是：结构体字段变更后，旧缓存反序列化失败，json.Unmarshal 静默忽略字段，导致业务读到“半空”数据。
- 键格式统一为
v2:user-service:user:1001，其中v2是序列化协议版本，升级时改前缀即可隔离 - 所有缓存操作封装进
CacheService，内部自动拼接前缀、处理json.Marshal/json.Unmarshal，禁用gob - 避免在 handler 中直接调用
rdb.Get()，否则 context 无法透传，goroutine 泄漏风险高
穿透/击穿/雪崩得在 Go 层拦截，不是加个 Redis 就完事
这三类问题不会因为用了 Redis 自动消失。比如穿透——查 user:-1 或超长 ID，Redis 返回 nil 后业务层直接查 DB，攻击者批量刷就拖垮数据库。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 穿透：对空结果也写缓存，值设为
{"empty":true}，TTL 缩短至 60–120 秒，并加参数校验（如 ID ≤ 0 直接 reject） - 击穿：热点 key 过期瞬间，用
SETNX+ Lua 脚本实现逻辑锁，只放行一个回源请求，其余等待后重试Get() - 雪崩：TTL 别写死，改为
baseTTL + rand.Intn(120)，错开过期时间；对配置类数据，可改用Ristretto本地 LRU 作二级缓存，TTL 设为远程的 1/3
更新策略选 Cache-Aside，但删缓存失败必须异步重试
“先更新 DB，再删缓存”看似简单，但删缓存失败（网络抖动、Redis 拒绝）会导致长期不一致。尤其金融类服务，账户余额缓存错一分钟就可能资损。
- 删除操作必须带重试：最多 3 次，间隔指数退避（100ms → 300ms → 900ms），失败记录日志并告警
- 别用
DEL同步删，优先用EXPIRE设极短 TTL（如 1 秒），降低失败影响面 - 写操作后不立即删本地缓存（如有），而是发消息通知其他实例清理，或依赖
Ristretto.OnEvict回调统一处理
真正难的不是连上 Redis，而是让每个缓存操作都携带上下文、可监控、可降级、可追溯。比如 Get() 超时后是否走 DB 降级，Set() 失败要不要打 metric，空值缓存是否该计入命中率——这些细节不提前定义，上线后只能靠日志拼凑问题。
