java包装类序列化/反序列化核心陷阱是npe、==误比较、协议兼容性差及装箱性能问题；须判空防npe、一律用equals()比较、dto统一用包装类、避免原生序列化、警惕自动装箱副作用。
Java中包装类在序列化和反序列化时，核心问题是：它们看似“只是基本类型的对象版”，但行为上既保留了对象特性，又隐含基本类型语义，稍不注意就会掉进NPE、比较异常、数据失真等坑里。
空值处理不当引发NullPointerException
包装类可为null，而基本类型不能。反序列化时若JSON字段缺失或显式为null（如"score": null），Gson/Jackson会正确设为Double score = null；但后续若直接拆箱：double value = user.getScore();，运行时抛出NullPointerException。
- 业务判断前务必判空，例如用
Objects.nonNull(user.getScore())或user.getScore() != null - 避免在条件表达式中直接使用自动拆箱，如
if (user.getId() > 0)→ 改为if (Objects.nonNull(user.getId()) && user.getId() > 0) - DTO设计阶段就明确字段是否允许为空，必要时用
@Nullable标注，配合Lombok的@Data谨慎生成getter
==比较误用导致逻辑错误
用==比较两个Integer，结果取决于是否命中缓存（默认-128~127）。Integer a = 100, b = 100时a == b为true；但Integer c = 200, d = 200时c == d为false——这不是bug，而是JVM规范行为。
- 所有包装类的值比较必须用
.equals()，包括Boolean.TRUE.equals(flag)这种写法更安全 - 不要依赖
Integer.valueOf(x) == Integer.valueOf(y)做相等判断，哪怕x、y都在缓存范围内 - 集合中去重、Map键匹配等场景，天然依赖
equals()和hashCode()，无需额外处理
序列化协议与中间件兼容性风险
Java原生Serializable接口虽支持包装类，但存在严重局限：版本不兼容、反序列化漏洞、跨语言不可用。消息队列（如Kafka/RabbitMQ）消费端通常不走Java原生序列化，而是用JSON、Avro等通用格式。
- 避免在消息体中混用基本类型和包装类（如
int id+String name），JSON缺失id字段时，Gson可能静默赋0，掩盖真实数据缺失 - 统一用包装类定义DTO字段，确保null语义可传递、可识别
- 若用Kafka，推荐
StringDeserializer+ Gson手动解析，而非ByteArrayDeserializer走Java原生反序列化（后者有安全风险且难调试）
自动装箱/拆箱带来的隐蔽性能与逻辑问题
看似方便的语法糖，在高频调用或循环中可能放大开销；更危险的是它掩盖了null检查责任。
- 频繁装箱（如
list.add(i)循环中i为int）会创建大量临时对象，考虑用IntStream或原始类型集合库（如Eclipse Collections）优化 - 方法参数接收
Integer但内部做了拆箱运算，调用方传入null即崩——应在方法入口用Objects.requireNonNull()或文档明确约定非空 - 泛型容器（如
Map<string object></string>）中存取包装类时，注意类型擦除后无法校验，建议封装成带类型信息的TypedValue<t></t>结构
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
