直接用 redis.Client 写业务易出问题，因连接不复用、超时未设、错误被吞、未用 Pipeline，轻则响应变慢，重则连接打满、服务雪崩；Go 的 redis 客户端线程安全但封装不当会导致连接池失效、上下文失控、资源泄漏。
为什么直接用 redis.Client 写业务容易出问题
直接在每个函数里 new 一个 redis.Client，连接不复用、超时没设、错误被吞、pipeline 没用——轻则响应变慢，重则 Redis 连接打满、服务雪崩。Go 的 redis 客户端（比如 github.com/redis/go-redis/v9）本身是线程安全的，但封装不当会让连接池失效、上下文失控、资源泄漏。
关键不是“能不能用”，而是“怎么避免让 redis 成为瓶颈”。常见踩坑点：
-
redis.NewClient()调用后没配WithContext()，导致超时控制失效 - 没显式设置
MaxConnAge和MaxIdleConns，连接老化堆积、内存缓慢上涨 - 用
Get()后直接调Val()，忽略Err()判断，空指针 panic 或静默失败 - 批量操作硬写 for 循环 + 单条
Set()，没走Pipeline或MSet，QPS 直降 5–10 倍
封装核心：一个带健康检查和上下文透传的 RedisStore
不要暴露原始 *redis.Client，而要封装成结构体，把连接初始化、重试策略、日志埋点、上下文默认注入都收口。
示例结构：
立即学习“go语言免费学习笔记（深入）”；
type RedisStore struct {
client *redis.Client
logger *zap.Logger // 可选，但建议带上
}
<p>func NewRedisStore(addr, password string, db int) <em>RedisStore {
rdb := redis.NewClient(&redis.Options{
Addr: addr,
Password: password,
DB: db,
DialTimeout: 5 </em> time.Second,
ReadTimeout: 3 <em> time.Second,
WriteTimeout: 3 </em> time.Second,
PoolSize: 20, // 根据并发量调，别盲目设 100+
MinIdleConns: 5, // 避免冷启动抖动
MaxConnAge: 30 * time.Minute, // 强制刷新老连接，防 TIME_WAIT 堆积
})</p><pre class="brush:php;toolbar:false;">// 必做：加 Ping 检查，失败就 panic 或返回 error（根据你的启动策略）
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()
if err := rdb.Ping(ctx).Err(); err != nil {
panic(fmt.Sprintf("failed to connect redis: %v", err))
}
return &RedisStore{client: rdb}}
注意：PoolSize 不等于最大并发数，它影响的是连接池大小；MinIdleConns 保证常驻连接，减少首次请求延迟。
读写方法必须接收 context.Context，且默认带 timeout
业务层调用时不该自己拼 context，而应由模块提供带默认超时的封装方法。否则每个地方都要写 context.WithTimeout(ctx, 500*time.Millisecond)，极易漏或写错。
推荐写法：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
func (r *RedisStore) GetString(ctx context.Context, key string) (string, error) {
// 默认 300ms 超时，业务可传入更短或更长的 ctx
if _, ok := ctx.Deadline(); !ok {
var cancel context.CancelFunc
ctx, cancel = context.WithTimeout(ctx, 300*time.Millisecond)
defer cancel()
}
<pre class="brush:php;toolbar:false;">val, err := r.client.Get(ctx, key).Result()
if errors.Is(err, redis.Nil) {
return "", nil // 注意：redis.Nil 是正常情况，不是 error
}
if err != nil {
r.logger.Warn("redis GetString failed", zap.String("key", key), zap.Error(err))
return "", err
}
return val, nil}
func (r RedisStore) SetString(ctx context.Context, key, value string, ttl time.Duration) error { if _, ok := ctx.Deadline(); !ok { var cancel context.CancelFunc ctx, cancel = context.WithTimeout(ctx, 300time.Millisecond) defer cancel() }
return r.client.Set(ctx, key, value, ttl).Err()
}
要点：
- 别用
MustXXX()方法，它 panic —— 在服务中不可控 - 区分
redis.Nil和其他 error，前者是 key 不存在，后者才是故障 - 所有方法签名带
ctx，强制上游传入，避免后台 goroutine 持有 request-scoped context
批量操作别绕开原生 API，优先用 MGet/MSet 和 Pipeline
for 循环单条操作是最常见性能黑洞。Go-redis 提供了高效的批量接口，但要注意适用边界：
-
MGet/MSet：适用于 key 数量固定、结构简单、无依赖的场景，比如一次取用户基础信息的多个字段 -
Pipeline：适合混合命令（如先GET再INCR）、或需要原子性但又不想用 Lua 的情况；注意 pipeline 不是事务，失败需手动处理 - 避免在 pipeline 中塞太多命令（>100 条），网络包过大可能触发 Redis 的
proto-max-bulk-len限制
示例：
func (r *RedisStore) GetMultiString(ctx context.Context, keys []string) ([]string, error) {
if len(keys) == 0 {
return []string{}, nil
}
<pre class="brush:php;toolbar:false;">vals, err := r.client.MGet(ctx, keys...).Result()
if err != nil {
return nil, err
}
result := make([]string, len(vals))
for i, v := range vals {
if v != nil {
result[i] = v.(string)
}
}
return result, nil}
注意 MGet 返回的是 []interface{}，需要类型断言；如果某些 key 不存在，对应位置是 nil，不是 redis.Nil。
真正复杂逻辑（比如“读-改-写”）还是得靠 Lua 脚本或 WATCH/MULTI/EXEC，模块里可以预留 Eval 封装入口，但别默认鼓励用。
最易被忽略的一点：连接池参数和业务并发模型不匹配时，context.DeadlineExceeded 错误往往不是网络问题，而是连接池耗尽卡在 dial 阶段——这时候看 redis.Client.PoolStats() 比查网络更有效。
