多层捕获分支嵌套中空指针崩溃源于三元运算符、算术表达式及方法返回值参与运算时的自动拆箱，而非异常未捕获；需重点检查condition ? 0.0 : somedouble等类型不一致的三元表达式，统一用double.valueof(0.0)或optional封装修复。
多层捕获分支嵌套中因基本类型与包装类隐式转换引发的空指针崩溃，本质不是异常没被捕获，而是根本没走异常路径——它在类型推断和自动拆箱阶段就直接崩了，连 try 块都还没真正“进入”。排查关键在于跳出“只看 catch”的惯性，聚焦三元运算符、算术表达式、方法返回值参与运算这三类高危现场。
盯紧三元运算符的类型统一过程
这是最隐蔽也最高发的源头。只要 ?: 两侧一个是基本类型字面量（如 0.0、1），另一个是可能为 null 的包装类（如 Double、Integer），JVM 就会强制把整个表达式类型提升为基本类型，进而触发对 null 的拆箱。
- 检查所有形如 condition ? 0.0 : someDouble 或 flag ? 1 : count 的表达式，其中 someDouble 或 count 是包装类型且可能为 null
- 用 IDE 的“类型推断提示”功能悬停查看该三元表达式的实际编译后类型——如果显示为 double 或 int，而非 Double 或 Integer，风险已确认
- 修复不是加 try-catch，而是统一为引用类型：condition ? Double.valueOf(0.0) : someDouble 或更清晰地写成 condition ? Double.ZERO : someDouble
扫描参与算术/比较运算的包装类变量
任何涉及 +、-、*、/、>、==（非 equals）等操作的包装类变量，只要其值为 null，就会在运算开始前触发自动拆箱。
- 搜索代码中所有类似 int result = count + 10;、if (value > 0.0)、total += amount; 的语句，确认 count、value、amount 是否为 Integer、Double 等可空类型
- 特别注意日志拼接：log.info("count=" + count); 中的 + 也会触发拆箱
- 修复方式：显式判空再运算，或改用 Objects.requireNonNull(count, "count must not be null") + 10 提前暴露问题
审查方法链式调用中的“假安全”节点
像 service.getData().size() 这种写法，看起来 getData() 返回 null 时 .size() 不会执行（短路），但若 getData() 实际返回的是 Integer，而你紧接着写了 service.getData() + 1，那 null 拆箱就发生在 getData() 调用之后、+1 之前，跟后续方法无关。
- 对所有返回包装类的方法调用，检查其下游是否直接参与了算术、比较或三元运算
- 不要依赖 “前面判了空，后面就安全”——每个独立表达式都需单独评估其拆箱风险
- 推荐策略：将易空的包装类返回值立即转为 Optional，后续用 map、orElse 处理，彻底隔离拆箱逻辑
这类崩溃不会出现在 catch 块里，也不会有栈帧显示“抛出了 NullPointerException”，它发生在字节码执行的瞬间。定位核心是逆向追踪：从崩溃行号出发，逐个检查该行所有子表达式的操作数类型，尤其警惕那些看起来“只是个数字”的地方。
