NullPointerException 最典型触发点是对 null 值调用实例方法或访问非静态字段；高频场景包括 map.get 链式调用、构造参数未校验、Optional.of(null)、JSON 反序列化字段缺失；避免方式有入参强制非空、返回空集合或 Optional、Objects.requireNonNull 兜底、拆解链式调用。
Java 中的空对象（null）本身不报错，报错的是你对它的非法操作——比如调用方法、访问字段、解引用数组等。
NullPointerException 出现在哪儿最典型
最常见的触发点是：对 null 值调用实例方法或访问非静态字段。例如：
String s = null; int len = s.length(); // 抛出 NullPointerException
其他高频场景包括：
-
map.get(key)返回null后直接链式调用，如map.get("x").toString() - 构造函数参数未校验，导致内部字段为
null，后续使用时报错 - 流式操作中
Optional.of(null)直接抛异常，而Optional.ofNullable(null)才安全 - JSON 反序列化时字段缺失，Jackson 默认设为
null，后续未判空就调用
如何避免 NPE：从防御到契约
单纯靠 if (obj != null) 太琐碎，也容易漏。更可持续的做法是分层防御：
立即学习“Java免费学习笔记（深入）”；
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 入参强制非空：用
@NonNull（Lombok）或@NotNull（JSR-303），配合 IDE 或编译期检查 - 返回值明确语义：集合类优先返回空集合（
Collections.emptyList()）而非null；对象可封装为Optional<t></t> - 工具类兜底：用
Objects.requireNonNull(obj, "msg")在关键入口快速失败，比静默null更易定位 - 避免链式调用裸奔：把
user.getAddress().getCity().toUpperCase()拆成带判空的步骤，或改用Optional.ofNullable(user).map(User::getAddress).map(Address::getCity).map(String::toUpperCase).orElse("N/A")
IDE 和 Lombok 怎么帮你提前发现问题
现代 IDE（IntelliJ / Eclipse）能基于注解推断空值流，但前提是代码有信号：
- Lombok 的
@RequiredArgsConstructor+@NonNull字段，会在构造时自动插入Objects.requireNonNull - 启用 IntelliJ 的
Nullability annotations检查后，@Nullable方法返回值若被无检查地调用，会标黄警告 - 不要忽略编译器提示的「Condition 'x != null' is always true」——这往往说明你前面已经做过非空断言，后面又重复判空，逻辑可能冗余或矛盾
注意：@NonNull 是契约，不是魔法。它不阻止你传 null，只在运行时校验或编译期提醒。
日志里看到 NPE，怎么快速定位根源
堆栈第一行往往只告诉你「哪行崩了」，但真正的问题在上游——那个本该非空却为 null 的变量是谁给的？
- 看异常栈顶的
at com.xxx.XxxService.doSomething(XxxService.java:42)，别只盯42行，往上翻几行，找谁调用了这个方法、传了什么参数 - 如果用了 Spring，检查
@Autowired字段是否因组件未扫描/配置错误而没注入成功（此时字段为null） - 单元测试里故意传
null，确认是否覆盖了空路径；生产环境可加临时日志：log.debug("user = {}", user);，注意user.toString()本身也可能 NPE，要用Objects.toString(user)
最麻烦的不是 NPE 本身，而是它掩盖了设计缺陷：一个本不该出现 null 的地方反复出现，说明契约没对齐，或者职责划分模糊。
