本文详解如何在 Redis 中正确存储和反序列化 Go 结构体切片：通过 Redigo 的 RPUSH/LRANGE 配合 Gob 编码，或改用 SET/GET 存储整体编码后的切片，避免 EOF 错误与类型不匹配问题。
本文详解如何在 redis 中正确存储和反序列化 go 结构体切片：通过 redigo 的 `rpush`/`lrange` 配合 gob 编码，或改用 `set`/`get` 存储整体编码后的切片，避免 eof 错误与类型不匹配问题。
Redis 本身不理解 Go 的 gob 编码格式，它仅将数据视为字节流（或字符串）。当你使用 RPUSH 将多个 gob 编码的对象依次推入列表时，每个对象是独立编码、独立存储的字节序列；Redis 并不会自动将其合并为一个 gob 可识别的切片结构。因此，直接对整个 LRANGE 返回结果调用 gob.Decode() 必然失败（报 decode error: EOF），因为 gob 解码器期望的是单个完整编码值（或一个已按 gob 协议序列化的切片），而非多个拼接的 gob 流。
✅ 正确方案一：逐项解码（适用于需独立访问单个元素的场景）
当使用 RPUSH 存储时，必须用 redis.ByteSlices 获取 [][]byte，再对每个字节切片单独创建 gob.Decoder：
// 存储端（修正版：避免 string 转换，提升性能）
var buf bytes.Buffer
if err := gob.NewEncoder(&buf).Encode(obj); err != nil {
log.Fatal(err)
}
_, err := d.Conn.Do("RPUSH", "objects", buf.Bytes()) // 使用 Bytes()，非 String()
if err != nil {
log.Fatal(err)
}
// 读取端：逐项解码
items, err := redis.ByteSlices(d.Conn.Do("LRANGE", "objects", "0", "-1"))
if err != nil {
log.Fatal("LRANGE failed:", err)
}
var objects []YourStructType // 替换为实际结构体类型，如 []User
for _, data := range items {
var obj YourStructType
if err := gob.NewDecoder(bytes.NewReader(data)).Decode(&obj); err != nil {
log.Printf("Decode failed for item: %v", err)
continue
}
objects = append(objects, obj)
}⚠️ 注意事项：
- redis.ByteSlices 是关键——它将 Redis 的字符串列表准确转为 [][]byte，而非 []string（后者会触发 UTF-8 解码，破坏二进制 gob 数据）；
- 每次 gob.Encode() 必须作用于单个值（非切片），否则解码时类型不匹配；
- 若结构体含未导出字段、非 gobsafe 类型（如 chan, func, unsafe.Pointer），需实现 GobEncode/GobDecode。
✅ 正确方案二：整体编码存储（适用于批量读取、无需单元素操作）
若你始终以切片为单位读写（例如全量缓存配置列表），推荐将整个切片一次性 gob 编码后存为 Redis 字符串（SET/GET）：
// 存储：编码整个切片
values := []YourStructType{{...}, {...}}
var buf bytes.Buffer
if err := gob.NewEncoder(&buf).Encode(values); err != nil {
log.Fatal(err)
}
if _, err := d.Conn.Do("SET", "objects", buf.Bytes()); err != nil {
log.Fatal(err)
}
// 读取：一次性解码为切片
data, err := redis.Bytes(d.Conn.Do("GET", "objects"))
if err != nil {
log.Fatal("GET failed:", err)
}
var objects []YourStructType
if err := gob.NewDecoder(bytes.NewReader(data)).Decode(&objects); err != nil {
log.Fatal("Gob decode failed:", err)
}此方式性能更优（一次网络往返 + 一次解码），且语义清晰：Redis 中的 "objects" 键即代表一个完整的 gob 序列化切片。
? 关键总结
- ❌ 不要对 LRANGE 返回的 []string 或错误转换的 []byte 直接调用 gob.Decode —— 这是 EOF 错误的根源；
- ✅ 优先选择 redis.ByteSlices + 循环解码（支持原子性单元素操作）或 redis.Bytes + 整体解码（更高吞吐，适合只读批量场景）；
- ✅ 写入时始终使用 buffer.Bytes() 而非 buffer.String()，避免不必要的 UTF-8 编码开销；
- ? 若需类型安全，建议定义具体结构体类型（如 []User）而非 []interface{}，既提升可读性，又规避运行时类型断言风险。
两种模式并无绝对优劣，选择依据是你的业务访问模式：高频随机索引 → 用 RPUSH/LRANGE；全量读写为主 → 用 SET/GET + 整体 gob。
