NPE并非源于变量本身判空失效，而是发生在后续调用中——如compareTo(null)、add(null)、toString()或日志自动调用等隐式操作；需结合堆栈定位具体抛出点，统一在初始化、运算、日志等全链路做null兜底。
做了 null 判空后还报 NullPointerException，说明 NPE 并非直接来自该 BigDecimal 变量本身，而是发生在它参与的后续操作中——比如调用其方法、参与运算、或被传入其他不允许 null 的上下文。
检查判空逻辑是否真正生效
常见错误是判空写法有误，导致看似判了空，实则没拦住：
- 用了
== null判空，但变量其实是空字符串转成的BigDecimal(" ")或new BigDecimal(null)—— 后者构造时就抛 NPE，根本走不到你写的判空位置； - 判空写在了变量赋值之后，而 NPE 发生在赋值过程中（例如
BigDecimal.valueOf(map.get("amount"))，但map.get("amount")返回 null，valueOf(null)直接炸）； - 判空对象不是你实际使用的那个变量（比如判了
a，但后面用的是未判空的b，或用了方法返回的新对象）。
重点排查调用链上的隐式 null 操作
BigDecimal 自身方法多数不接受 null，但容易忽略的“雷区”包括：
-
compareTo(null)：传入 null 会立即 NPE，不是返回 -1； -
add(other)、multiply(other)等运算方法，若other是 null，直接抛异常； -
toString()、toPlainString()在对象为 null 时当然 NPE，但更隐蔽的是：日志打印时自动调用toString()（如log.info("val={}", bd)），如果bd是 null 就在这里崩； - 作为 JSON 序列化字段（如 Jackson），若字段为 null 且配置了非空要求（如
@JsonInclude(JsonInclude.Include.NON_NULL)一般没事，但自定义序列化器可能没处理 null）。
确认 NPE 堆栈指向的具体位置
这是最关键的一步。不要只看报错信息，要完整看 stack trace：
立即学习“Java免费学习笔记（深入）”；
- 找到最上面那个
at xxx.xxx.xxx line XX，定位到抛异常的代码行； - 看那行是不是
bd.compareTo(...)、bd.add(someNullVar)、someMethod(bd)这类调用； - 如果是
someMethod(bd)，继续往下看，这个方法内部是否对bd做了未判空的.doubleValue()或.setScale(...)？
防御性写法建议
别只靠“判一次空”，要让 null 在整个使用链中无害化：
- 初始化时就避免 null：
BigDecimal val = Optional.ofNullable(raw).map(BigDecimal::new).orElse(BigDecimal.ZERO); - 运算前统一兜底：
bd1 == null ? bd2 : bd1.add(bd2 == null ? BigDecimal.ZERO : bd2)，或封装工具方法； - 日志中防 null 打印：
log.info("val={}", Objects.toString(bd, "null"))； - IDE 中开启 “Nullability annotations”（如
@Nullable/@NotNull），配合静态检查提前发现潜在问题。
不复杂但容易忽略。核心就是：NPE 不一定出在声明处，而常藏在你信任它“已经不为空”后的第一次调用里。
