RPC调用中包装类处理核心是明确自动装箱/拆箱不穿透网络层，接口统一用包装类、序列化需对齐null策略、业务代码须防御性判空、测试须覆盖跨进程null场景。
Java 中包装类在 RPC 调用中处理基础类型与对象的转换，核心在于理解“自动装箱/拆箱”在序列化、反序列化和接口契约层面的边界——它只在 JVM 内存中生效，不会自动穿透到网络传输层。RPC 框架（如 Dubbo、gRPC、Spring Cloud OpenFeign）实际传输的是序列化后的字节流，此时基础类型和包装类是完全不同的数据结构，必须显式对齐。
接口定义阶段：统一使用包装类，避免 null 语义歧义
基础类型（如 int、boolean）在 Java 中不能为 null，而 RPC 调用中常需表达“未设置”、“缺失字段”或“可选参数”。若服务提供方用 int age，消费方传 null 会直接报错（如 Dubbo 的 NullPointerException 或序列化失败）；反之，若提供方用 Integer age，但消费方传 0，就无法区分“年龄为 0”和“未提供年龄”。
- 对外暴露的 RPC 接口（Service 接口 + DTO）一律使用包装类（
Integer、Boolean、Long等） - 在文档或注释中明确每个字段是否允许
null，例如：/** 年龄，null 表示未填写 */ - 避免混用：不要在一个 DTO 中对同一语义字段一会儿用
int，一会儿用Integer
序列化配置阶段：确认框架对包装类 null 的支持策略
不同 RPC 框架和序列化器（JSON、Hessian、Protobuf）对 null 的处理差异很大：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
Dubbo + Hessian2：默认支持
Integer为null，但需确保双方 Hessian 版本一致，否则可能反序列化成 0 或抛异常 -
gRPC + Protobuf：原生不支持 null；需用
optional int32 age = 1;（proto3 后期版本）或包装消息类型（如message IntValue { int32 value = 1; }）来模拟可空语义 -
Spring Cloud OpenFeign + JSON（Jackson）：默认将
null序列化为 JSONnull，但需检查@JsonInclude(JsonInclude.Include.NON_NULL)是否被全局启用——若启用，null字段会被丢弃，导致接收方得到默认值（如Integer变成null，但int字段反序列化为 0）
运行时阶段：防御性处理拆箱操作，防止 NPE
即使接口和序列化都用了包装类，业务代码中仍可能因疏忽直接拆箱，比如 user.getAge() + 1。一旦 getAge() 返回 null，运行时立即抛 NullPointerException。
立即学习“Java免费学习笔记（深入）”；
- 禁止裸调用
.xxxValue()或参与算术/逻辑运算前不判空，例如避免if (user.getStatus().booleanValue()) - 推荐写法：
• 使用Objects.equals(a, b)比较包装类
• 使用Optional.ofNullable(user.getAge()).orElse(0)提供默认值
• 在 Service 实现内部，对入参做快速校验：if (dto.getAge() == null) throw new IllegalArgumentException("age 不能为空");
测试与兼容阶段：覆盖 null 场景的端到端验证
很多 RPC 问题只在真实调用链路中暴露。仅单元测试 DTO 序列化不够，必须验证跨进程场景：
- 写集成测试：启动真实 Provider 和 Consumer，显式传
null值，验证能否成功调用、返回、不抛 NPE - 检查日志或 WireShark 抓包，确认网络传输的 payload 中对应字段确实是
"age": null（JSON）或正确编码（Protobuf） - 升级 RPC 框架或序列化器后，重点回归测试所有含包装类的接口，因为新版本可能改变 null 处理逻辑（如 Jackson 2.12+ 对
Optional的支持变化）
