RPC接口返回中，使用基本类型还是包装类？

面试官： RPC 接口返回值，用基本类型还是包装类？为什么？

你：

结论很明确：绝大部分情况用包装类，除非你能 100% 保证永远有值且不会出现 null。

为什么包装类更安全？核心三个点：

基本类型无法表达“没有” RPC 调用天生就是不可靠的，网络超时、下游查不到数据、反序列化失败，都可能让你拿不到预期值。如果你接口定义返回 int，碰到这些情况，框架通常只能给你塞个默认值 0。下游调用方拿到 0，分不清是真的业务结果为 0（比如“用户余额为 0”），还是因为出错了才拿到的 0。业务逻辑直接就走偏了。

而 Integer 可以直接返回 null，明确告诉调用方“这个字段无意义 / 没查到”，调用方做 null 判断就行，语义清晰，不会把“系统错误”当成“正常值”。

序列化与反序列化的坑很多 RPC 框架底层是 JSON 或二进制序列化。如果服务端返回 JSON，字段值是 null，客户端用 int 接收时，框架在反序列化时一旦试图把 null 赋值给基本类型，就会直接抛 NullPointerException，整个调用直接失败。用 Integer 就不会有这问题。
数据库返回值天然可能是 null 大部分 RPC 接口最后都要查数据库。数据库字段就允许 null，DAO 层返回的 Integer 可能就是 null。如果你为了省事定义成 int，就会在某次查询返回 null 时拆箱失败，炸一个 NPE。

那基本类型什么时候用？

这个字段的语义决定了它绝对不能为 null，比如主键 ID、分页页码、数量必须从 1 开始等。这时用 int 甚至配合 @NotNull 校验，可以从设计上强制约束，避免到处判空。
性能极敏感的海量调用场景，且已经用压测证明了装箱拆箱开销是瓶颈。但这种场景极其罕见，不要提前优化。

总结一句话：除非你能保证永远不 null，否则用包装类，让 null 替你背锅，比莫名 NPE 或业务逻辑跑偏好一百倍。