redisson 默认使用 kryo 实现高效、无侵入的序列化，无需对象实现 `serializable`；java 原生序列化仅在显式配置时启用，可通过 `codec` 灵活替换为 json、avro 或自定义序列化器。
在基于 JCache（JSR-107）规范集成 Redisson 作为缓存提供者时，序列化行为是核心关注点之一——它直接影响性能、兼容性与可维护性。值得注意的是，Redisson 并不依赖 Java 原生序列化（java.io.Serializable）作为默认机制，而是采用更轻量、更快、且无需强制实现 Serializable 接口的 Kryo 序列化器。
✅ 默认行为：Kryo 序列化（零配置即生效）
当你通过 RedissonConfiguration 或 RedissonClient 创建 CacheManager 时（例如使用 RedissonCachingProvider），若未显式指定 Codec，Redisson 将自动启用 KryoCodec（自 3.17.0+ 版本起为默认）。Kryo 的优势包括：
- ✅ 支持 java.time.* 类型（如 LocalDateTime、ZonedDateTime）开箱即用；
- ✅ 支持标准集合（List、Map、Set）及常见 POJO，无需实现 Serializable；
- ✅ 序列化体积小、速度快，显著优于 Java 原生序列化；
- ✅ 自动注册常用 JDK 类型，避免手动注册开销。
示例：无需任何改动即可安全缓存时间对象和列表：
Cache<String, List<LocalDateTime>> cache = cacheManager.getCache("events", String.class, List.class);
cache.put("today", Arrays.asList(LocalDateTime.now(), LocalDateTime.now().plusHours(1)));⚠️ 注意：Redis 中的数据并非 Java 原生字节流
你观察到 Redis 中存储的是二进制数据，但这不是 ObjectOutputStream 生成的 java.io.Serializable 字节流。Kryo 输出的是紧凑的二进制格式（非可读、不可跨语言直接解析），因此不能用 redis-cli 直接解读内容——这是正常现象，不代表使用了原生序列化。
? 如何自定义序列化行为？
如需更强的可读性、跨语言兼容性或已有 JSON 生态，可轻松切换 Codec。例如，使用 JsonJacksonCodec（推荐用于调试或微服务间共享缓存）：
Config config = new Config();
config.setCodec(new JsonJacksonCodec()); // 启用 Jackson JSON 序列化
config.useSingleServer().setAddress("redis://127.0.0.1:6379");
RedissonClient redisson = Redisson.create(config);
CacheManager cacheManager = Caching.getCachingProvider().getCacheManager(
null,
redisson,
Collections.singletonMap(RedissonCachingProvider.REDISSON_CLIENT, redisson)
);? 提示：JsonJacksonCodec 要求被缓存对象具备无参构造函数及标准 getter/setter；对 java.time.* 需额外注册 JavaTimeModule（Redisson 内置已支持，无需手动配置）。
❌ 不建议使用 Java 原生序列化
尽管可通过 SerializationCodec 强制启用，但应避免：
- 性能差（反射开销大、字节流冗长）；
- 安全风险高（反序列化漏洞）；
- 版本兼容性脆弱（serialVersionUID 变更即失效）；
- 无法序列化 lambda、匿名内部类等现代 Java 特性。
✅ 最佳实践总结
| 场景 | 推荐方案 |
|---|---|
| 默认生产环境 | 保持 KryoCodec（高性能、低侵入） |
| 调试/日志友好 | 切换 JsonJacksonCodec（人类可读） |
| 跨语言系统集成 | 使用 AvroCodec 或自定义 Protobuf Codec |
| 自定义类型支持 | 为 Kryo 注册 Serializer，或为 Jackson 添加 Module |
总之，Redisson 的序列化设计以开发者体验和运行时效率为核心：无需 Serializable，不绑定 JDK 限制，且完全可插拔。合理选择 Codec，既能保障类型安全与兼容性，又能兼顾性能与可观测性。
