三元运算符类型推导遵循最小上界（lub）规则，当分支含基本类型与包装类（如int和integer）时，结果类型统一为基本类型，触发隐式拆箱；若包装类分支为null，则运行时抛nullpointerexception。
因为 Java 编译器必须为整个三元表达式确定一个**唯一、明确的结果类型**，而当两个分支类型不兼容（比如 int 和 Integer）时，它会依据 JLS §15.25 的最小上界（LUB）规则进行类型推断——这个过程常导致一方被强制转成另一方的“底层基本类型”，从而触发隐式拆箱；若该包装类变量为 null，就立刻抛出 NPE。
类型推断不是“选一个”，而是“统一成一个”
三元运算符不接受“类型并集”。编译器不会让结果有时是 Integer、有时是 int。它必须选出一个公共类型，使得两个分支都能无歧义地转换过去。常见情形包括：
-
int字面量（如42）与Integer变量混用 → 推导结果类型为int，Integer分支被迫拆箱 -
double与Double混用 → 结果为double，Double分支拆箱 -
Boolean与boolean混用 → 结果为boolean，Boolean分支拆箱 -
null与Integer混用 → 结果为Integer（null可赋给任何引用类型），但后续若赋给int，仍会触发拆箱
自动装箱其实常是“先拆后装”的陷阱
你以为写的是 Integer x = cond ? 1 : someInt 很安全？不一定。如果接收变量是 Integer，而分支一个是 int 字面量、另一个是 int 变量，编译器仍可能把整个表达式定为 int 类型，再对结果做一次 Integer.valueOf(...) 装箱——这时若中间计算涉及 null（比如 someInt 实际来自 Double.valueOf(null)），就会在装箱阶段炸掉。
典型反例：
-
Double d = flag ? 0.0 : getNullableDouble();→0.0是double，getNullableDouble()返回Double，结果类型推为double，null被拆箱 → NPE -
Integer i = cond ? null : 1;→ 合法，结果类型是Integer；但若下一行写int j = i;，就又触发拆箱 → NPE
String 为什么没事？因为它不涉及基本/包装转换
String 是纯引用类型，没有对应的基本类型。所以 "hello" 和 str（String 变量）天然同构，无需类型提升，不触发任何装箱或拆箱。这也是为什么三元用于字符串、集合、自定义对象时几乎不会因类型问题出 NPE，而一碰 Integer/Double/Boolean 就容易翻车。
怎么避免这种“看似无害实则危险”的装箱行为
核心是切断编译器的自动类型统一路径：
- 两个分支都用包装类型：用
Integer.valueOf(1)替代1，用Double.valueOf(0.0)替代0.0 - 改用
if-else：逻辑清晰，类型不跨分支混合，null可原样保留 - 用
Optional显式建模可空性，把null处理提前到业务层 - 在 CI 中接入 SpotBugs 或自定义 Checkstyle 规则，禁止基本类型字面量与包装类型共存于同一三元表达式
