redis set命令只支持字符串值,存对象需先序列化为json;注意处理日期、枚举等特殊字段,避免额外引号,跨语言场景优先选json而非java原生序列化。

Redis set 方法不支持直接存对象
Redis 的 set 命令底层只接受字符串类型(string)作为值,传入 Java 对象、Python 字典、Go struct 等原生对象会触发序列化异常或类型错误。这不是 Redis 客户端的 bug,而是协议层硬性限制——服务端根本不认识“对象”这个概念。
常见报错现象包括:WRONGTYPE Operation against a key holding the wrong kind of value(如果 key 之前存过其他类型)、java.lang.ClassCastException(Jedis/Lettuce)、TypeError: Object of type XXX is not JSON serializable(Python redis-py)。
- 必须先将对象转成字符串,再调用
set - 推荐用 JSON 序列化,因其跨语言、可读性强、客户端普遍支持
- 注意空值、循环引用、时间类型等特殊字段,JSON 库默认可能不处理
JSON 序列化时容易漏掉的三类字段
不是所有对象都能无损转成 JSON。比如 Java 的 LocalDateTime、Python 的 datetime、自定义枚举、含有 private 字段但没 getter 的 POJO,都会在序列化时报错或丢数据。
- Java(Jackson):需注册
JavaTimeModule处理日期,或用@JsonFormat注解 - Python(json.dumps):传入
default参数,例如lambda o: o.isoformat() if isinstance(o, datetime) else str(o) - Go(encoding/json):结构体字段必须首字母大写(exported),且加
json:tag 控制键名和忽略空值
示例(Python):
import json
from datetime import datetime
<p>data = {"name": "alice", "created": datetime.now()}</p><h1>❌ 报错:TypeError: Object of type datetime is not JSON serializable</h1><h1>json.dumps(data)</h1><h1>✅ 正确处理</h1><p>json_str = json.dumps(data, default=lambda o: o.isoformat() if hasattr(o, 'isoformat') else str(o))
redis_client.set("user:1", json_str)</p>
set 时要不要手动加引号?JSON 字符串本身已含双引号
不需要,也绝不能额外包裹引号。JSON 序列化结果已经是合法字符串字面量,比如 {"name":"alice","age":25} —— 这本身就是字符串内容,不是代码语法里的字面量。
- ❌ 错误写法:
redis.set("key", '"' + json.dumps(obj) + '"')→ 存进去的是"{"name":"alice"}"(开头结尾多了一对引号) - ✅ 正确写法:
redis.set("key", json.dumps(obj)) - 验证方式:用
redis-cli get key查看原始返回,应为纯 JSON 文本,无额外引号
性能与兼容性:为什么不用 Java 的 ObjectOutputStream?
虽然 Java 可以用 ObjectOutputStream 序列化对象为 byte[] 再存 Redis,但实际项目中几乎没人这么干。
- 无法跨语言:PHP/Node.js 客户端读不出 Java 二进制格式
- 版本脆弱:类结构一改(增删字段、改包名),反序列化直接失败
- 体积更大:Java 序列化包含类名、字段描述等元信息,JSON 更紧凑
- 调试困难:Redis CLI 里看到一堆不可读字节,排查问题只能靠猜
真正需要高性能且同构环境(全 Java)的场景,可考虑 Kryo 或 FST,但仍建议优先走 JSON + 显式 DTO 转换,把序列化逻辑收口、可控、可测。
复杂点往往不在“怎么存”,而在于“谁负责序列化、谁负责反序列化、字段变更时如何平滑过渡”。JSON 至少让这个问题暴露得早、看得见。










