go-redis连接Redis时传context.Background()有问题，因无超时和取消机制，易致goroutine无限阻塞；应使用WithTimeout或HTTP请求上下文；SetNX用于原子加锁，Scan需调大Count避免高频往返，JSON存取须确保字段可导出并带tag，client.Close()须显式调用且仅在进程退出前执行。
go-redis 连接 Redis 时 ctx 传 context.Background() 真的没问题？
不是所有场景都适合用 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，吞吐极低。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 通过
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 连接堆积。这个点，文档里轻描淡写，实际排查起来最耗时间。
