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)
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 至少让这个问题暴露得早、看得见。
