三目运算符强制拆箱导致NPE，因任一分支为基本类型时编译器会统一类型并隐式拆箱null包装类；应先判空或统一用包装类型避免。
三目运算符里自动拆箱最容易翻车——不是因为语法难，而是它悄悄把 null 包装类拉进基本类型运算，一碰就抛 NullPointerException。核心问题在于：只要两个分支中有一个是基本类型，编译器就会强制统一为基本类型，触发隐式拆箱。
三目运算符为什么会强制拆箱
Java 规定：当三目表达式的两个分支类型不一致，且其中一个是基本类型（如 int）、另一个是对应包装类（如 Integer）时，整个表达式的类型会被“提升”为基本类型。为达成这个目标，编译器会在运行时对包装类分支执行自动拆箱。
例如：
-
int result = flag ? getValue() : 0;—— 若getValue()返回null，这里会立刻调用null.intValue()，NPE 爆发 -
Boolean b = flag ? getFlag() : false;—— 若getFlag()返回null，也会在取值后立即拆箱
最稳妥的写法：先判空，再参与三目
别让 null 进入三目运算的任一分支。推荐用显式非空判断兜底，而不是依赖三目自身逻辑：
- 用三元嵌套：
int value = flag ? (obj.getValue() != null ? obj.getValue() : 0) : 0; - 用
Objects.requireNonNullElse（Java 9+）：int value = flag ? Objects.requireNonNullElse(obj.getValue(), 0) : 0; - 或提前提取并校验：
Integer temp = obj.getValue(); int value = flag ? (temp != null ? temp : 0) : 0;
替代方案：绕开基本类型分支
如果业务允许，让三目两边都保持包装类型，彻底避开拆箱环节：
-
Integer result = flag ? getValue() : Integer.valueOf(0);—— 两边都是Integer，无拆箱 - 后续真正需要
int时，再做一次带判空的显式拆箱：int safeInt = result != null ? result : 0;
检查所有可能返回包装类的地方
尤其注意这些高频“陷阱源”：
- Map 的
get()方法（如map.get("key")返回Integer，直接用于三目右侧极易 NPE） - Optional 的
orElse(null)或未处理的get() - 数据库 ORM 框架的字段映射（如 MyBatis 返回
Integer字段为null） - JSON 反序列化时缺失字段，默认生成
null包装类
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
