三元运算符中基本类型字面量与可空包装类型混用会触发JVM强制拆箱导致NPE；应改用if-else、显式包装或Optional避免隐式类型转换。

直接看字节码或加断点观察运行时实际执行路径，比凭直觉猜“条件为 false 就不会执行另一分支”更可靠。三元运算符的类型推断和拆箱发生在表达式求值阶段，与逻辑是否短路无关。

确认是否涉及包装类与基本类型混用

检查三元表达式两个分支的原始类型：

• 一边是 基本类型字面量（如 0.0、1、true）
• 另一边是 可能为 null 的包装类型变量（如 Double value、Integer count、Boolean flag）
• 只要存在这种组合，JVM 就会按 JLS §15.25.2 规则将整个表达式类型统一为对应基本类型，强制对包装变量执行拆箱

快速验证空指针是否源于拆箱

把原三元表达式临时替换成等价的 if-else 分支：

• 如果替换后不再抛 NPE，基本可锁定是三元运算符的类型推断问题
• 例如：Double v = cond ? 0.0 : value; → 改为
• Double v; if (cond) v = 0.0; else v = value;
• 后者不触发类型提升，null 被原样保留

用 javap 查看字节码确认拆箱调用

编译后执行 javap -c YourClass，搜索关键指令：

• 看到 invokevirtual ... Double.doubleValue 或 Integer.intValue 等调用，说明发生了自动拆箱
• 若该方法调用前没有空值校验，而变量又确实为 null，NPE 就必然发生
• 这个步骤能绕过源码表象，直击 JVM 实际行为

静态扫描与编码规范加固

在 CI 流程中加入检测规则：

• 禁止三元表达式中同时出现基本类型字面量与包装类型变量
• 要求所有涉及 Double/Integer/Boolean 的三元分支必须显式使用 Double.valueOf(0.0)、Integer.valueOf(1)、Boolean.TRUE 等包装形式
• 推荐用 Optional.ofNullable(x).orElse(y) 替代复杂三元逻辑，语义清晰且无隐式转换