三元运算符本身不引发空指针异常，但分支类型不一致（如double与null的Double）会触发自动拆箱导致NullPointerException；应统一为引用类型、使用Optional、拆分if-else或结合@NonNull注解预防。
三元运算符本身不会引发空指针异常，但当两个分支类型不一致（比如一个为基本类型字面量、另一个为对应包装类且可能为 null）时，Java 会强制统一类型——通常提升为基本类型，从而触发对 null 的自动拆箱，最终抛出 NullPointerException。避免的关键不是禁用三元运算符，而是阻断“隐式拆箱”路径。
统一两边的操作数类型为引用类型
只要两个分支都是同一包装类型（如 Double），就不会发生类型提升和拆箱：
- ❌ 错误写法（
0.0是double，value是Double）：Double v = value != null && value.isNaN() ? 0.0 : value; - ✅ 正确写法（显式用
Double.valueOf(0.0)或0.0d包装）：Double v = value != null && value.isNaN() ? Double.valueOf(0.0) : value;
或更简洁地：Double v = value != null && value.isNaN() ? 0.0d : value;
用 Optional 显式表达“可能为空”的语义
把逻辑从“值判断 + 三元选择”转为“Optional 链式处理”，既避免拆箱，又增强可读性与契约性：
Double v = Optional.ofNullable(value).filter(d -> d.isNaN()).orElse(0.0d);- 如果后续还需处理非 NaN 的有效值，可继续链式调用：
Double result = Optional.ofNullable(value)<br> .filter(d -> !d.isNaN())<br> .orElse(0.0d);
提前校验并分离逻辑，必要时退回到 if-else
当条件复杂或涉及多个包装类型操作时，硬塞进三元运算符反而增加风险。此时优先保障安全性和可维护性：
立即学习“Java免费学习笔记（深入）”；
- 先明确
value是否为null或NaN，再单独赋值：Double v;<br>if (value == null) {<br> v = 0.0d;<br>} else if (value.isNaN()) {<br> v = 0.0d;<br>} else {<br> v = value;<br>} - 这种写法虽略长，但每一步类型清晰、无隐式转换，调试和修改都更直接。
借助注解和静态检查工具预防
在方法参数或字段上使用 @NonNull（Lombok 或 JetBrains 注解），配合 IDE 实时提示，能在编码阶段就发现潜在的 null 流入点：
public Double computeValue(@NonNull Double input) { ... }- 结合
Objects.requireNonNull(input)在入口处快速失败，比在三元表达式中崩溃更容易定位问题根源。
