三元运算符类型转换陷阱源于自动拆箱：当分支含基本类型与对应包装类时，编译器按jls规则统一为基本类型，强制拆箱null导致npe；string等纯引用类型无此问题；规避方法包括统一用包装类、改用if-else或optional。
三元运算符的类型转换陷阱，核心就藏在自动装箱与拆箱的协同机制里——它不是“要不要转”，而是“必须统一成一个类型”，而这个统一过程常常强制触发拆箱，一旦遇到 null，立刻抛出 NullPointerException。
类型推导会强制选择基本类型作为结果类型
当两个分支一个是基本类型（如 0.0、42、true），另一个是对应包装类（如 Double、Integer、Boolean）时，Java 编译器依据 JLS §15.25 的最小上界（LUB）规则，把整个表达式的结果类型定为那个基本类型。这意味着：
- 包装类分支必须被自动拆箱，才能和基本类型对齐；
- 如果该包装类变量实际为 null，拆箱调用 doubleValue()、intValue() 或 booleanValue() 就会直接失败。
例如：
-
Double d = flag ? 0.0 : nullableDouble;→ 结果类型推为double→nullableDouble被拆箱 →null触发 NPE -
boolean b = cond ? nullBoolean : false;→ 结果类型是boolean→nullBoolean拆箱失败
看似安全的赋值，其实暗含“先拆后装”
即使接收变量是包装类，比如 Integer i = cond ? 1 : someInt;，编译器仍可能先将整个三元表达式定为 int 类型，再对结果执行 Integer.valueOf() 装箱。问题在于：
- 若 someInt 实际来自 Double.valueOf(null) 或数据库映射的空值，它本身已是 null；
- 那么在“统一为 int”这一步，就会先尝试对 null 拆箱，NPE 在此发生，根本走不到装箱那步。
String 等纯引用类型不中招，正是因为没拆箱这回事
String 没有对应的基本类型，所以 "hello" 和 str（String 变量）天然属于同一类型体系，无需类型提升，也不触发任何装箱/拆箱。null 可以原样保留、安全传递。同理，List、Map、自定义对象等纯引用类型组合使用三元运算符，几乎不会因类型转换引发 NPE。
避开陷阱的关键动作
本质是阻断编译器“自动统一到基本类型”的路径：
- 两个分支都用包装类型：写
Double.valueOf(0.0)或Double.ZERO，而不是0.0 - 改用
if-else：类型各自独立，null不参与任何隐式转换 - 用
Optional显式封装可空性，把空值判断提前到业务逻辑层，而非塞进三元表达式里做类型博弈
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
