应全局单例初始化redis.Client，使用redis.NewClient()创建一次并赋值包级变量，所有操作必须传c.Request.Context()，显式设置Read/WriteTimeout，正确区分redis.Nil（业务逻辑）与真实error，并暴露PoolStats供观测。
怎么在Gin里初始化一个可用的Redis客户端
直接用 go-redis/v8 初始化，别手写连接池或复用 net.Conn。关键不是“连上”，而是“连得稳、用得对”。
常见错误是把 redis.Client 当局部变量传进 handler，结果每次请求都新建连接，很快耗尽文件描述符。
正确做法是全局单例 + context 透传：
- 在
main()或bootstrap/redis.go中调用redis.NewClient()创建一次，赋值给包级变量（如var RDB *redis.Client） - 所有操作必须带
context.Context，推荐用c.Request.Context()而非全局context.Background()，避免超时传递失效 - 务必调用
RDB.Ping(ctx).Err()检查连接，失败时 panic 或 log 后 exit，不要静默忽略 - 如果用配置文件（如 viper），地址、密码、DB 号要从配置读，别硬编码
"localhost:6379"
为什么 Get/Set 会返回 redis.Nil 而不是报错
redis.Nil 是正常响应，表示 key 不存在 —— 它不是 error，但容易被当成 error 处理，导致接口返回 500。
典型误用：
val, err := rdb.Get(ctx, "user:123").Result()
if err != nil {
c.JSON(500, gin.H{"error": err.Error()})
return
}
这段代码会让 key 不存在时也返回 500。正确处理方式：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 先判断
err == redis.Nil：这是业务逻辑分支，应返回 404 或空数据 - 再判断其他 err（如网络中断、超时）：这才是真错误，才该返回 500
- 用
result, err := rdb.Get(ctx, key).Result()后，优先检查err类型，而不是直接if err != nil
如何避免 Gin handler 里 Redis 调用阻塞整个请求
Redis 默认是同步阻塞调用，但 go-redis/v8 所有方法都支持 context 控制超时，不设 timeout 就可能卡死 goroutine。
必须显式设置：
- 在
redis.Options里配ReadTimeout和WriteTimeout（例如 5 * time.Second） - 每次调用前构造带 timeout 的 ctx：
ctx, cancel := context.WithTimeout(c.Request.Context(), 3*time.Second)，并在 defer 中cancel() - 别依赖服务端
timeout配置（如 redis.conf 的timeout），那是空闲连接关闭时间，不影响单次命令 - 高并发场景下，考虑用
WithContext()替代直接传 ctx，避免中间件修改 context 导致取消信号丢失
封装 Redis Client 时最容易漏掉的三件事
自己封装 RedisClient 很常见，但多数人只写了 Set/Get，却忽略了底层行为差异和运维需求。
- 没包装
Pipeline或TxPipeline：批量操作仍用多次 round-trip，性能差一倍以上 - 没统一处理
redis.Nil和context.Canceled：前者是业务态，后者是调用方主动中断，日志里混在一起无法区分问题来源 - 没暴露
PoolStats()接口：上线后不知道连接数、等待队列长度、超时次数，出问题只能猜
真正稳定的集成，不是“能存能取”，而是超时可控、错误可分、状态可观测。别跳过健康检查接口和 metrics 上报点。
