核心是选序列化协议并配全redistemplate：禁用jdk序列化（体积大、不安全、难调试），优先用jackson json（可读、跨语言、易配置），高频稳定场景可选protobuf（更小更快但需.proto定义），且key/value/hash等各序列化器须全覆盖配置。
Java 在 Redis 中规范存储自定义对象，核心不是“怎么存”，而是“用什么协议序列化 + 怎么配 RedisTemplate”。直接用默认 JDK 序列化会埋下体积大、跨语言难、反序列化漏洞等隐患，必须主动替换。
优先选 Jackson JSON 序列化（最实用）
对大多数业务系统来说，Jackson 是平衡可读性、兼容性和开发效率的首选。它把对象转成标准 JSON 字符串，Redis 存的是 String 类型，调试时直接 GET user:1001 就能看清内容。
- 配置时明确指定
Jackson2JsonRedisSerializer或GenericJackson2JsonRedisSerializer，避免泛型擦除导致反序列化失败 - 为
ObjectMapper添加常用配置：启用WRITE_DATES_AS_TIMESTAMPS避免时间类型乱码，注册JavaTimeModule支持LocalDateTime - key 必须用字符串序列化（
StringRedisSerializer），value 用 JSON，hash 的 field 也建议统一用字符串，避免类型混用
高性能场景考虑 Protobuf（需权衡）
当单日缓存调用量超千万、对象字段多且结构稳定（如用户画像、订单快照），Protobuf 的体积压缩率和序列化速度优势明显——实测比 JSON 小 30%～40%，序列化快 2 倍以上。
- 前提是接受“先写 .proto 文件 → 生成 Java 类”这一额外流程，不能动态增删字段
- 需自定义
RedisSerializer实现，封装Schema和Parser，避免每次 new 对象 - 不适用于需要人工查数据或前端直读的场景，因为二进制不可读
务必避开 JDK 原生序列化
即使项目初期图省事用了 JdkSerializationRedisSerializer，上线前也应清理掉。它的字节流含完整类名、包路径、字段签名，一旦类重构（改名、删字段、升级 JDK），所有缓存数据立即失效；更严重的是，恶意构造的 payload 可触发远程代码执行。
- Redis 中看到
\xAC\xED\x00\x05开头的数据，基本就是 JDK 序列化残留，应批量迁移 - Spring Boot 2.6+ 已默认禁用
enableDefaultTyping，但旧版遗留风险仍高 - 若必须兼容老数据，可用临时工具类做一次转换，不要长期混合使用
自定义序列化器要覆盖全链路
一个完整的 RedisTemplate 配置，不能只设 setValueSerializer。不同操作对应不同序列化器，漏配会导致异常：
-
setKeySerializer：用于 key（如"user:1001"），必须是StringRedisSerializer -
setValueSerializer：用于 value（对象主体），按需选 Jackson 或 Protobuf -
setHashKeySerializer和setHashValueSerializer：操作 Hash 时分别序列化 field 名和 field 值 -
setListSerializer等同理，尤其在存 List时容易忽略
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
