Java序列化兼容性关键在反序列化时类型匹配、null处理及分支路径一致性；须统一用包装类声明字段，配置反序列化器行为，并显式判空后再使用，辅以覆盖边界数据的兼容性测试。
Java 中基本类型和包装类的序列化兼容性问题，核心不在“能不能序列化”，而在于反序列化时字段类型与传入数据是否匹配、null 值如何处理、以及不同分支路径下类型不一致引发的行为差异。尤其在 JSON（Jackson/Gson）等主流反序列化场景中，混用 int 和 Integer、boolean 和 Boolean 会导致静默失败、NPE 或逻辑错乱。要保证兼容，关键不是“怎么序列化”，而是“怎么定义 + 怎么配置 + 怎么使用”。
统一字段声明为包装类是兼容前提
基本类型（如 int age）无法接收 null；一旦 JSON 中该字段为 "age": null，Jackson 默认直接报 JsonMappingException。而 Integer age 可以正常设为 null，语义清晰。
更危险的是分支结构：比如根据 type 字段决定反序列化成 User（含 int age）或 Admin（含 Integer age），同一字段在不同子类中类型不一致，反序列化器可能走不同路径，导致部分实例字段为 0（默认值）、部分为 null，业务判断直接失真。
- 所有参与反序列化的 DTO/POJO 中，数值型（
int/long/float/double）和布尔型（boolean）字段，一律声明为对应包装类（Integer/Long/Float/Double/Boolean） - 父类与子类、v1/v2 版本 DTO 中同名字段，必须保持类型完全一致；若旧版用
long orderId，新版改Long orderId，需同步升级所有调用方或加兼容层
配置反序列化器显式处理 null 和缺失值
即使用了包装类，不同库对 null、缺失字段、空字符串的默认行为也不同。不能依赖“默认能过”。
- Jackson：在字段上加
@JsonSetter(nulls = Nulls.SKIP)跳过 null 赋值（保留原值或 null），或@JsonSetter(defaultValue = "0")设默认数字；全局配置可设DeserializationFeature.ACCEPT_NULL_AS_EMPTY（对集合/Map 生效）或FAIL_ON_NULL_FOR_PRIMITIVES = false（慎用，仅临时兜底） - Gson：通过
GsonBuilder().serializeNulls().setFieldNamingPolicy(...)控制，但对基本类型仍不支持 null，所以仍需先统一为包装类
避免自动拆箱参与业务逻辑判断
反序列化后拿到 Integer age，如果写 if (user.getAge() > 18)，表面看没问题，但一旦 getAge() 返回 null，此处会立即抛 NullPointerException——这个 NPE 往往出现在服务运行数小时后，极难复现。
- 所有从反序列化对象读取的包装类字段，在参与算术运算、比较、条件判断前，必须显式判空
- 推荐写法：
if (Objects.nonNull(user.getAge()) && user.getAge() > 18) - 禁止在
if、switch、return x + 1等上下文中直接使用包装类变量，IDE 中开启「boxing/unboxing inspection」可高亮风险点
兼容性测试必须覆盖边界数据
光跑通 happy path 不够。真实环境中常出现：
- 前端漏传字段 → JSON 中无
age字段 - 数据库 NULL 导出为
"age": null - 旧版本客户端发来
"age": ""或"age": "abc" - 多模块共用 DTO，某模块升级后字段变
Long，另一模块仍用long - 测试用例应包含：含 null 字段、缺失字段、非法字符串、空字符串、超范围数值（如
Long.MAX_VALUE + 1）的 JSON 输入，验证反序列化结果是否符合预期（字段为 null / 抛异常 / 设默认值）
不复杂但容易忽略
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
