关键在于三元表达式类型推断强制统一分支类型，包装类与基本类型混用时会触发对null的隐式拆箱；应通过字节码反编译、ide警告（如intellij提示“unboxing may produce npe”）、spotbugs等静态检查及分步调试验证执行路径。
排查这类问题，关键不是看条件是否成立，而是看三元表达式整体的类型推断结果——编译器会强制统一两个分支的类型，一旦涉及包装类与基本类型的混合，就可能触发对 null 的隐式拆箱。
看字节码确认是否发生拆箱
反编译 class 文件是最直接的方式。例如：
- Long x = null; Long y = true ? x : 100L; 反编译后实际等价于 true ? x.longValue() : 100L ——x.longValue() 在运行时调用，x 为 null 就抛 NPE；
- 同理，Boolean a = null; boolean b = false; i == 1 ? a : b 会被转成 a.booleanValue() : b，空值调用即崩溃。
用 IDE 警告和静态检查工具提前拦截
现代 IDE（如 IntelliJ IDEA）会在编辑时标出高风险写法：
- 当三元运算符左右操作数一个是基本类型字面量（如 0.0、100L、true），另一个是可为 null 的包装类变量（如 Double value、Boolean flag）时，会提示“Unboxing of ‘xxx’ may produce NullPointerException”；
- 启用 SpotBugs 或 ErrorProne 插件，能自动检测 ?: 中跨类型隐式转换导致的潜在拆箱点。
运行时加断点或日志验证执行路径
不要只依赖“条件为 false 就安全”的直觉。在真实场景中，条件往往是动态的：
- 把三元表达式拆成独立变量赋值，例如：Double v = condition ? 0.0 : value; → 拆为两行并分别设断点，观察哪一分支真正参与了类型统一；
- 在分支中插入日志或调试语句（注意不能放方法调用，否则改变执行逻辑），确认 JVM 实际选择的是哪个分支——因为类型推断发生在编译期，但拆箱动作发生在所选分支求值时。
快速验证是否类型不一致
写一个最小可复现片段，用不同组合测试：
- 两端都用包装类：? Double.valueOf(0.0) : value → 安全；
- 两端都用基本类型：? 0.0 : value.doubleValue() → 但此时 value 为 null 仍会 NPE；
- 混用且条件导向 null 分支：? value : 0.0，value=null → 看是否崩溃，即可反向验证是否发生了拆箱。
