Redis存储Java对象应按业务约束选序列化方案：纯Java环境优选Kryo/FST，跨语言用Protobuf，调试场景可用JSON；须规避JDK原生序列化漏洞与版本耦合问题；推荐统一序列化入口加格式标识，并对小对象优先使用Hash结构存储。
在 Redis 中存储 Java 对象时，选择合适的序列化方案本质是权衡性能、安全、兼容性与可维护性。没有“绝对最佳”，但有“更合适”的字节流方案——关键看你的系统边界和演进节奏。
明确业务约束再选序列化方式
不同场景对序列化的要求差异很大：
- 如果服务全部基于 Java，且对象结构稳定（如内部微服务间通信），优先考虑 Kryo 或 FST：它们比 JDK 原生序列化快 3–5 倍，体积小 40% 以上，且无需强制实现
Serializable接口。 - 若需跨语言读取（如 Go/Python 服务也要消费该缓存），Protocol Buffers（Protobuf） 是更稳妥的选择——需定义 .proto 文件，但生成的二进制紧凑、版本兼容性好、反序列化开销极低。
- 若对象仅作临时缓存、生命周期短、调试频率高（比如开发/测试环境），JSON 字节流（UTF-8 编码） 可接受：用 Jackson 的
writeValueAsBytes()直接输出 byte[]，虽比二进制慢 2–3 倍，但 Redis CLI 中可直接GET key查看内容，排查问题不依赖反序列化工具。
避开 JDK 原生序列化的坑
JDK 自带的 ObjectOutputStream 虽开箱即用，但在生产 Redis 场景中应主动规避：
-
反序列化漏洞风险高：Redis 一旦被注入恶意 payload，
ObjectInputStream可能触发远程代码执行（如 Apache Commons Collections 利用链）。 -
类版本强耦合：哪怕只是加了个
transient字段或改了serialVersionUID，旧数据就无法反序列化，导致缓存击穿或服务异常。 - 字节膨胀明显：相同对象，JDK 序列化结果通常比 JSON 大 30%～50%，比 Protobuf 大 5–10 倍，加剧内存与网络压力。
统一序列化入口 + 版本标识
无论选哪种方案，都要封装成可插拔的序列化器，并为每个 key 的 value 加入轻量元信息：
立即学习“Java免费学习笔记（深入）”；
- 在字节流头部写入 1–2 字节的格式标识（如
0x01= Kryo,0x02= Protobuf,0x03= JSON），避免硬编码反序列化逻辑。 - 对频繁变更的业务对象，可在元信息中嵌入小版本号（如
0x01 0x02表示 Kryo v2），支持灰度升级时新旧格式共存。 - 使用 Spring Data Redis 时，推荐自定义
RedisTemplate的valueSerializer，而非每次手动序列化/反序列化——既保证一致性，也便于后续替换方案。
小对象直存 Hash，大对象才序列化
不是所有对象都适合整体序列化。Redis 的 Hash 结构天然适配 POJO：
- 对字段少、更新粒度细的对象（如用户基础信息），用
HSET user:1001 name "Alice" age 25 city "Beijing"存储，支持单字段读写、原子更新、部分失效，比序列化后整个覆盖更高效。 - 仅当对象嵌套深、含集合/Map、或需强一致性原子操作时（如订单+明细+优惠券组合），才走序列化路线；此时建议用 Kryo/Protobuf，避免 JSON 解析开销和类型丢失（如
long被转成Double）。 - 超大对象（>100KB）应拆分：主体存 Hash 或 String，附件（如 base64 图片）单独 key 存储，用 pipeline 批量读取，降低单次网络往返压力。
