go中往redis存结构体等非字符串值必须显式序列化，因client.set只接受string或可转string的类型；误传struct/map会panic；推荐json（跨语言）或gob+base64（go专属、保类型），且需注意字段导出、key命名、ttl单位等细节。
Go 语言往 Redis 发送命令时，string 类型参数本身不需要额外序列化——它已经是 Redis 能直接接收的格式。真正需要序列化的，是结构体、map、slice 等非字符串 Go 值。所谓“字符串作为参数”只是表象，背后常隐含类型转换陷阱。
为什么 string 参数有时会出错？
常见错误不是 string 本身有问题，而是你误把非字符串值（比如 struct、map[string]interface{}）直接传给 redis.StringCmd 或 client.Set 的 value 参数，导致运行时报错：cannot use myStruct (type User) as type string in argument to client.Set。
- Go 不允许隐式类型转换，
client.Set(ctx, key, value, ttl)的value必须是interface{}，但底层实际调用时会尝试调用fmt.Sprint或反射转字符串，结果不可控 - 若结构体含未导出字段或指针，
fmt.Sprint输出可能是&{0xc000123456}这类地址信息，存进 Redis 后无法还原 - 直接传
[]byte是安全的，但如果你传的是string，它会被自动转成[]byte—— 这步没问题；问题出在“怎么得到这个string”
struct 存 Redis 必须显式序列化
你真正要解决的，是把 Go 结构体变成 Redis 能存的 string 或 []byte。标准库提供两种主流路径：
-
encoding/json：字段必须导出（首字母大写），推荐加json:tag 控制键名和空值行为；生成 UTF-8 字符串，可读性强，跨语言友好，但不保留 Go 特有类型（如time.Time变成字符串，nilmap 变成null） -
encoding/gob+encoding/base64：无需 tag，支持接口、未导出字段、time.Time、func（不序列化）等；体积更小、速度更快；但仅限 Go 内部使用，且反序列化时目标 struct 类型必须完全一致（包括包路径）
示例（JSON）：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
u := User{Name: "Alice", Age: 30}
data, _ := json.Marshal(u)
client.Set(ctx, "user:1", data, 0)
示例（gob+base64）：
var buf bytes.Buffer enc := gob.NewEncoder(&buf) enc.Encode(u) encoded := base64.StdEncoding.EncodeToString(buf.Bytes()) client.Set(ctx, "user:1", encoded, 0)
map[string]interface{} 和 slice 怎么处理？
这类动态结构体是 JSON 的天然适配场景，但要注意：
-
json.Marshal对nilslice 输出null，而空 slice[]int{}输出[]；反序列化时需统一约定 -
gob能原样保留nilvs 空 slice 区别，但要求反序列化时变量声明类型与序列化时一致（不能用interface{}直接接收） - 如果 map key 是非字符串类型（如
int），json会失败；gob支持，但 Redis 里存出来是二进制，调试困难 - 避免用
map[interface{}]interface{}—— JSON 和 gob 都不支持，运行时 panic
容易被忽略的边界点
真正踩坑的地方不在选 JSON 还是 gob，而在细节一致性：
- Redis key 名是否带前缀？多个服务共用一个 Redis 时，
"user:1"和"svc:user:1"混用会导致反序列化失败 - 过期时间单位是否统一？
time.Second和time.Minute混用容易设错 TTL - 反序列化时 struct 字段名大小写是否匹配？JSON 默认按字段名匹配，
Name对应"name"（除非加json:"name"） - 并发读写同一 key 时，没做类型断言或错误检查就直接
json.Unmarshal，可能 panic —— 必须先判断err != nil和返回值是否为nil
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
