Java中基本类型与包装类在JSON反序列化时核心差异在于null处理能力：int无法接收null而Integer可，故DTO应统一用包装类；需规避隐式拆箱NPE，保持继承体系字段类型一致，并权衡序列化null输出与语义准确性。
Java 中基本类型与包装类在序列化（尤其是 JSON 反序列化）时行为差异显著，核心在于 null 值的表达能力 和 类型强约束性。处理不当容易导致静默赋默认值、空指针异常或逻辑误判。关键不是“能不能用”，而是“在哪种上下文里必须用哪一种”。
JSON 反序列化时 null 字段的兼容性
当 JSON 数据中某个字段为 "age": null：
- 若 Java 字段声明为
int age：Jackson/Gson 默认拒绝反序列化，抛出JsonMappingException或静默失败（取决于配置），因为基本类型无法接收null； - 若声明为
Integer age：可成功接收null，字段值为null，语义清晰——表示“年龄未知/未提供”。
因此，所有可能映射外部数据（如 HTTP 请求体、数据库查询结果、MQ 消息）的 DTO/VO/POJO 类，数值和布尔型字段应统一使用包装类。
分支逻辑与多态反序列化中的类型一致性
在策略模式或继承结构中，不同子类对同一语义字段（如 status）可能用了不同类型：
立即学习“Java免费学习笔记（深入）”；
-
User类中定义Boolean enabled，Admin类中却定义boolean isActive； - 反序列化器根据
@JsonTypeInfo动态选择子类时，若 JSON 含"enabled": null，进入User路径成功，进入Admin路径则失败或被设为false（覆盖真实语义）。
解决方案是：在继承体系中，所有同名业务字段保持类型一致；若需兼容旧版基本类型字段，必须显式配置反序列化策略，例如 Jackson 的 @JsonSetter(nulls = Nulls.SKIP) 或 @JsonSetter(defaultValue = "false")。
避免自动拆箱引发的 NPE 隐患
即使字段声明为 Integer，一旦在业务代码中直接参与算术或条件判断，就可能触发隐式拆箱：
-
if (user.getAge() > 18)：若getAge()返回null，此处立即抛NullPointerException； -
int age = user.getAge();：同上，且堆栈信息可能指向业务行而非反序列化入口，难定位。
推荐写法：
- 用
Objects.nonNull(user.getAge()) && user.getAge() > 18替代直接比较； - 或提前校验并赋予业务默认值：
int age = Optional.ofNullable(user.getAge()).orElse(0);； - IDE 中启用 “Boxing/unboxing inspection”，高亮潜在风险点。
序列化输出的透明性与体积权衡
从序列化输出看，Integer 和 int 在 JSON 中都表现为纯数字（如 25），无格式差异。但内部处理有区别：
- 包装类序列化前会判空，若为
null则输出null（除非配置SerializationFeature.WRITE_NULLS = false）； - 基本类型永远输出具体值（如
0），无法区分“用户填了 0”和“字段未传”； - 内存与性能上，包装类因对象头和 GC 开销略大，但对一次请求的 DTO 来说可忽略——优先保障语义正确性。
不复杂但容易忽略。
