如何通过Go语言go-redis库详细操作，实现Golang中的Redis缓存策略？

本文共计872个文字，预计阅读时间需要4分钟。

不是所有场景都适合使用`context.Background()`. 它没有超时、取消功能，一旦网络卡住或Redis响应慢，`Get`、`Set`这类操作就会无限期阻塞goroutine。

• 线上服务必须设超时：用 context.WithTimeout(ctx, 500*time.Millisecond) 更稳妥
• HTTP handler 中建议复用请求上下文：r.Context()，便于统一取消
• 连接池耗尽时，没设 timeout 的请求会在 pool.Get 阶段卡住，错误日志里看不到 Redis 相关报错，只看到 goroutine 堆积

Set 和 SetNX 到底该选哪个？

SetNX（即 “SET if Not eXists”）是原子性加锁的基础，但很多人误以为 Set 加上 EX 参数就等价于加锁 —— 实际上不是。

• Set 是覆盖写，即使 key 存在也会强行更新值和过期时间，无法用于“仅首次设置”逻辑
• SetNX 返回 bool，true 表示成功抢到锁，false 表示 key 已存在；配合 WithExpiration 才构成完整锁语义
• 注意：SetNX 不支持同时设值 + 过期时间的原子操作（v9+ 支持 Set 的 XX/NX 选项），老版本务必用 SetNX + Expire 组合，但这两步不原子，有竞态风险

用 Scan 扫描大量 key 为什么越来越慢？

Scan 本身是游标式遍历，但默认每次只返回 10 个 key，实际要发几十甚至上百次 round-trip，吞吐极低。

• 通过 Count 参数增大单次返回量：client.Scan(ctx, cursor, "user:*", 1000).Val()
• 游标必须循环使用，不能重置为 0；结束标志是返回的 cursor == 0
• Redis 集群模式下 Scan 不跨 slot，只能扫当前节点，别指望它能全量枚举
• 生产环境慎用：会阻塞 Redis 单线程，高并发扫描可能拖慢其他命令

json.Marshal 后存 Redis，取出来却反序列化失败？

常见原因是结构体字段没加 JSON tag，或用了私有字段（首字母小写），导致序列化结果为空对象 {} 或缺失字段。

立即学习“go语言免费学习笔记（深入）”；

• 确保结构体字段可导出且带 tag：type User struct { Name string `json:"name"` }
• 反序列化前先检查原始字节数组是否为空：if len(data) == 0 { return nil, errors.New("empty redis value") }
• 更安全的做法是封装一层：GetJSON(ctx, key, &v)，内部自动处理空值、错误类型判断
• 注意：Redis 是纯字节存储，不校验 JSON 格式，坏数据存进去，取出来就是 invalid character 错误

最麻烦的其实是连接生命周期管理 —— client.Close() 必须显式调用，而且不能在每次请求后 close，否则连接池失效；但进程退出前忘了 close，会导致 TIME_WAIT 连接堆积。这个点，文档里轻描淡写，实际排查起来最耗时间。