结论：用go-redis/v8实现Cache-Aside最稳妥，但必须配好连接池、序列化和TTL；直接Get+Set易因未处理redis.Nil、缺少json tag、无超时控制或连接池配置不当导致缓存失效或服务卡死。
直接说结论：用 go-redis/redis/v8 实现缓存旁路（Cache-Aside）是最稳妥、最易维护的方案，但必须配好连接池、序列化方式和 TTL 策略，否则反而拖慢请求。
为什么不能直接用 Get + Set 就完事？
很多初学者写完 rdb.Get(ctx, key).Result() 发现缓存没生效，或者查一次数据库后缓存值是空字符串或 nil。这不是 Redis 问题，而是 Go 客户端返回值语义没吃透：
-
Get命中返回值，未命中返回redis.Nil错误（不是nil指针），必须显式判断errors.Is(err, redis.Nil) - 如果结构体字段没加
jsontag，json.Marshal会序列化出空对象或零值，导致缓存写入无效数据 - 忘记传
ctx或超时设置，高并发下连接卡死、goroutine 泄漏
go-redis/v8 连接池配置的关键参数
默认配置在生产环境极易打满连接，尤其当 QPS > 500 时。必须手动调优：
-
PoolSize：建议设为 CPU 核数 × 4 ~ 8，不要盲目设成 100+；过大会占用 Redis 连接数，过小会导致排队等待 -
MinIdleConns：至少设为PoolSize / 2，避免冷启动时频繁建连 -
MaxConnAge：设为 30m，强制轮换老化连接，防止 TCP TIME_WAIT 积压 -
ReadTimeout/WriteTimeout：建议统一设为 200ms，比数据库查询超时短 50ms，确保缓存失败能快速降级
示例片段：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
opts := &redis.Options{
Addr: "redis:6379",
PoolSize: runtime.NumCPU() * 6,
MinIdleConns: runtime.NumCPU() * 3,
MaxConnAge: 30 * time.Minute,
ReadTimeout: 200 * time.Millisecond,
WriteTimeout: 200 * time.Millisecond,
}缓存键设计与失效陷阱
缓存键看着简单，但错一个字符就全失效；失效逻辑写错，会导致脏数据长期滞留：
- 键名别拼错：比如商品缓存用
product:+id，别写成products:或漏掉冒号 - 删除缓存时别只删主键：比如更新商品价格，除了删
product:123，还要删关联的category:electronics:products这类聚合缓存 - 避免“先删缓存再更新 DB”：并发写时可能造成短暂脏读；推荐“更新 DB 成功后再删缓存”，并加一层重试（最多 2 次）
- TTL 别硬写死：高频变动数据（如库存）设 10s，低频静态数据（如用户资料）可设 2h，用
time.Hour * 2而非 magic number7200
JSON 序列化 vs gob 的实际取舍
很多人纠结该用 json 还是 gob，其实取决于你是否需要跨语言兼容或调试便利性：
- 用
json：调试时redis-cli get product:123能直接看到明文，适合业务初期、团队协作或需对接其他语言服务 - 用
gob：序列化体积小、速度快，但 Go 特有、不可读、版本升级易破溃（比如 struct 字段改名或增删） - 千万别混用：同一个 key 今天用 json 写，明天用 gob 读，
Unmarshal直接 panic - 建议统一用
json，并在 struct 上严格定义 tag，例如：type Product struct { ID string `json:"id"` }
真正容易被忽略的是——缓存穿透防护没做。比如恶意请求大量不存在的 product:-1，每次都会穿透到 DB。得在未命中时缓存一个空对象（带短 TTL，如 60s），并配合布隆过滤器预判。
