三元运算符类型推导基于最小上界（LUB）规则，可能引发隐式装箱/拆箱及空指针异常；如 Integer a = true ? 1 : null; int b = a; 运行时抛 NPE。
三元运算符（? :）在 Java 中要求两个分支表达式具有兼容类型，编译器会根据类型提升规则推导出一个公共的“结果类型”。这个过程看似自动便捷，却可能隐含类型擦除、装箱拆箱、以及空指针异常（NPE）风险——尤其当分支中存在 null 或包装类型时。
结果类型由两个分支的“最近公共父类型”决定
Java 不是取“更宽泛”的类型，而是按 JLS §15.25 规定，寻找二者在类型系统中的最小上界（Least Upper Bound, LUB）。常见情况包括：
- 两者都是基本类型（如
int和long）→ 按数值提升规则升为更宽类型（long） - 一者为基本类型，另一者为对应包装类（如
int和Integer）→ 结果类型为包装类（Integer），且基本类型会自动装箱 - 两者为不同包装类（如
Integer和Double）→ LUB 是Number（若无其他共同子类）或Object - 其中一者为
null→null可赋给任意引用类型，因此结果类型由另一分支决定（如Integer和null→ 结果为Integer）
自动装箱 + null 分支 = 静默的空指针风险
这是最易被忽视的陷阱。例如：
Integer a = true ? 1 : null;
表面看是安全的：1 被装箱为 Integer，null 也适配 Integer，结果类型是 Integer。但若后续直接解包：
int b = a; // 运行时抛出 NullPointerException！
因为 a == null，自动拆箱触发 NPE。该错误不会在编译期报错，也无明确警告。
避免空指针的实用建议
- 避免在三元运算符中混用基本类型与
null；统一使用包装类型，并显式判空再解包 - 若需返回基本类型，确保两个分支都不为
null（如true ? 1 : 0），或用Objects.requireNonNullElse(a, 0)等工具兜底 - 在涉及多种数字包装类时（如
Integer和Long），显式转型或使用泛型方法收口，防止意外退化为Number或Object - 启用 IDE 的空值分析（如 IntelliJ 的 “Data Flow Analysis”）或静态检查工具（如 SpotBugs、ErrorProne），它们能捕获此类潜在拆箱 NPE
小结：类型推导不等于安全推断
三元运算符的类型提升是编译期行为，它只保证“能合起来”，不保证“运行时不崩”。null 分支+自动拆箱构成典型反模式。理解 LUB 规则、警惕隐式装拆箱、配合工具检查，才能真正规避这类隐蔽风险。
