Go用redis.Client调用LPush和RPop前须确认连接状态，避免因未连通导致panic；需手动Ping校验、传非nil context、自行序列化数据、正确处理RPop空列表返回、并用RPopLPush等机制保障队列可靠性。
Go 用 redis.Client 调用 LPush 和 RPop 前必须确认连接状态
很多 panic 其实不是命令写错了，而是 redis.Client 还没连上 Redis 就直接发命令。比如调用 LPush 时返回 "redis: nil" 错误，大概率是 client := redis.NewClient(...) 后没等 client.Ping(ctx).Err() 成功就往下走了。
实操建议：
- 每次新建
redis.Client后，加一段健康检查：if err := client.Ping(context.Background()).Err(); err != nil { log.Fatal("failed to connect to redis:", err) } - 别在全局变量里直接初始化 client 然后裸用——Go 的 init 函数不等 Ping 完就可能执行后续逻辑
- 如果用的是
github.com/redis/go-redis/v9（v9 是当前主流），所有命令都要求传context.Context，别传nil，否则超时控制失效
LPush 插入数据时注意元素类型和编码
Go 的 LPush 接收 ...interface{}，但 Redis 列表只存字符串。你传 struct、int 或 nil 进去，它不会报错，而是调用 fmt.Sprintf("%v", v) 强转——这容易导致反序列化失败或长度异常。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 存了个
map[string]int{"a": 1}，取出来是"map[a:1]"字符串，JSON 解析直接 panic - 传了
nil，变成字符串"<nil>"</nil>，业务逻辑误判为有效值 - 整数太大（比如
int64(9223372036854775807)）转成字符串后占位多，列表体积膨胀快
正确做法是：自己做序列化，统一用 json.Marshal 或 msgpack 编码后再传给 LPush；读取时再 json.Unmarshal。别依赖默认格式化。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
RPop 返回 nil 不等于“出错”，而是“列表空了”
v9 客户端的 RPop 返回 redis.StringCmd，调用 .Result() 时，空列表会返回 ("<nil>", nil)</nil> ——第二个 nil 是 error，第一个才是值。很多人只检查 error，就误以为成功取到了 "" 或某个默认值。
典型翻车写法：
val, err := client.RPop(ctx, "mylist").Result()
if err != nil {
// 这里只拦住了网络错误、语法错误等，漏掉了空列表情况
log.Fatal(err)
}
// val 可能是 ""，也可能是 "<nil>"，但实际是空列表
安全写法：
- 先判断
val == "" && err == nil→ 大概率是空列表（Redis 规范中列表元素不允许为空字符串，所以RPop返回空串只可能因列表空） - 更严谨的做法是用
client.LLen(ctx, "mylist").Val()预查长度，但有竞态，仅用于调试 - 如果业务允许“无数据即退出”，直接把
val == "" && err == nil当作终止条件即可，不用额外报错
高并发下 LPush+RPop 不等于可靠队列
单纯靠这两个命令做任务队列，会丢数据或重复消费。比如消费者 RPop 成功后崩溃，还没处理完，消息就丢了；或者网络分区时，RPop 返回了值但客户端没收到响应，重试又取一次。
这不是 Go 或 Redis 的 bug，而是原生命令没提供原子性保障。真实场景要补三件事：
- 用
RPopLPush把任务从待处理列表移到正在处理列表（带过期时间），处理完再LRem清理 - 消费者必须实现幂等：同一个任务 ID 无论执行几次，结果一致
- 加 watchdog 机制，定期扫“正在处理列表”里超时未完成的任务，扔回待处理列表
这些不是“进阶技巧”，而是用 List 做队列时，第一天就得想清楚的事。不然压测一跑，丢任务比日志还快。
