三元运算符中包装类型与基本类型混合时会触发隐式拆箱，null值导致运行时npe；应改用objects.nonnull()、optional或统一包装类型等安全写法。
三元运算符（? :）在 Java 中要求两个操作数具有兼容类型，编译器会尝试对它们进行**类型提升（type promotion）**，以得到一个统一的“结果类型”。这个过程看似自动且安全，但当涉及包装类型（如 Integer、Boolean）与 null 时，容易触发**自动拆箱（unboxing）**，从而在运行时抛出 NullPointerException —— 而这种空指针往往隐蔽、难排查。
类型提升规则导致隐式拆箱
Java 规定：若三元表达式的两个分支一个是基本类型（如 int），另一个是对应包装类型（如 Integer），则整个表达式的结果类型为该基本类型；此时若包装类型分支为 null，JVM 会在运行时尝试将其拆箱为基本类型，直接触发 NPE。
-
int result = flag ? 10 : someInteger;—— 若someInteger == null，执行到此就会报错 - 即使
flag为true，看似不会走到null分支，但 JVM 仍会对两个分支做类型校验和潜在拆箱准备（实际执行路径中一旦进入 false 分支即崩溃） - 类似问题也出现在
boolean/Boolean、double/Double等组合中
常见高危写法示例
以下代码在编译期完全合法，但运行时极易崩溃：
-
int x = condition ? 5 : map.get("key");——map.get()返回Integer，可能为null -
boolean active = status != null ? status.isActive() : false;—— 表面安全，但如果status.isActive()返回Boolean（而非boolean），而另一分支是false（boolean），则整个表达式类型被推导为boolean，null结果会被拆箱 -
return flag ? obj.getValue() : 0;——obj.getValue()返回Integer，返回null时立刻 NPE
安全替代方案
避免依赖三元运算符的自动类型提升，改用显式、可控的逻辑：
- 用
Objects.nonNull()+ 显式分支代替：Integer val = map.get("key");<br>int x = Objects.nonNull(val) ? val : 0; - 提前判空并提供默认值：
Integer safeVal = Optional.ofNullable(map.get("key")).orElse(0); - 统一使用包装类型，避免混合：
Integer x = condition ? 5 : map.get("key");—— 此时结果是Integer，不会自动拆箱，NPE 风险转移至后续使用处（更明确、更易定位） - 必要时用普通 if-else，牺牲简洁换可读与安全
编译器不会警告，但 IDE 可辅助识别
javac 不会对这类潜在拆箱 NPE 发出警告，但现代 IDE（如 IntelliJ IDEA）在启用 inspections 时能标记“Conditional expression with boxed/unboxed types”类问题。建议开启：
Settings → Editor → Inspections → Java → Probable bugs → 'Ternary operator with boxed and unboxed types'
