分布式缓存中包装类应避免JDK序列化，优先转为原始值（如Integer用intValue()）存字符串或数字；需类型语义时选JSON/Protobuf；null值须显式约定策略。
Java 包装类（如 Integer、Long、Boolean 等）在分布式缓存中序列化时，核心问题不是“能不能”，而是“要不要保留类型信息”以及“用什么序列化方式更安全、高效、跨语言兼容”。直接依赖默认 JDK 序列化（Serializable）在分布式缓存中基本不可取，尤其在多服务、多语言或升级场景下极易出错。
避免使用 JDK 默认序列化
JDK 自带的 ObjectOutputStream 序列化有严重缺陷：强绑定类结构、版本敏感、不跨语言、体积大、存在反序列化漏洞风险。分布式缓存（如 Redis、Memcached、Tair、Aerospike）通常不运行业务代码，无法加载你的类定义，所以 Integer 对象若被 JDK 序列化后存入 Redis，其他服务（尤其是非 Java 服务）根本无法解析。
- 即使同为 Java 服务，不同版本的 JDK 或类字段变更也会导致
InvalidClassException - Redis 的
SET命令只认字节数组，JDK 序列化输出的是带类名、字段描述等元数据的二进制流，纯属“黑盒” - Spring Cache + RedisTemplate 默认用
JdkSerializationRedisSerializer就是典型踩坑配置，应立即替换
推荐方案：统一转为字符串或数字原始值
对数字包装类，最简单、最健壮的做法是**不序列化对象，只序列化其逻辑值**。分布式缓存本质是键值存储，你真正需要缓存的从来不是 Integer 这个对象，而是它代表的整数值 42。
-
写入时：调用
intValue()、longValue()、toString()显式提取原始值，再以字符串或数字格式存入（如 Redis 的SET key "100"或SET key 100） -
读取时：从缓存拿到字符串（如
"100"），用Integer.valueOf()或Long.parseLong()安全转换；若缓存支持原生数字类型（如 Redis 的INCR），可直接操作 - 这样完全绕过对象序列化，零依赖、零版本问题、天然跨语言（Python/Go 服务也能读
"100"并转成 int）
需要保留类型语义？用 JSON 或 Protobuf
极少数场景需区分 Integer 和 Long（比如下游严格校验类型），或缓存结构复杂（含包装类字段的 DTO）。此时应选通用、自描述的序列化协议：
立即学习“Java免费学习笔记（深入）”；
-
JSON（如 Jackson）：将
Integer.valueOf(42)序列化为42（数字字面量），Boolean.TRUE为true；类型信息隐含在 JSON 值类型中，解析端按需转成对应包装类 -
Protobuf / FlatBuffers：需先定义 schema（如
int32 value = 1;），生成代码后序列化为紧凑二进制；适合高性能、强契约场景，但引入额外构建步骤 - 关键点：无论选哪种，都应在序列化前把包装类解包（或让序列化器自动处理），而非传入
new Integer(42)让框架反射处理——Jackson 默认就能正确处理包装类，无需额外配置
注意 null 值和空值语义
包装类可为 null，但缓存中不能存 null 字节（Redis 不允许 SET key null）。必须明确约定空值策略：
- 用特殊字符串表示，如
"NULL_INTEGER"，读取时识别并返回null - 用独立的 exists 标记，如
SET key:val "100"+SET key:exists "1"，读取时先查 exists key - 更推荐：业务层避免缓存
null，改用 Optional 包装返回，或设计默认值（如 -1 表示未设置） - 切勿依赖序列化器自动跳过
null字段却不留痕迹——这会导致“缓存穿透”或逻辑歧义
