空指针异常是契约断裂的信号，需用objects.requirenonnull()在方法入口强制校验；string比较应写成"fixed".equals(unknownstr)；optional仅用于返回值；集合/数组返回空对象而非null。
空指针异常（NullPointerException）不是需要“兜底捕获”的运行时错误，而是设计或调用契约断裂的明确信号——它本该在代码写完前就被拦住。
Objects.requireNonNull() 必须用在方法入口
它不是可选工具，是接口契约的强制声明。一旦参数不该为 null，就必须在第一行校验。
-
Objects.requireNonNull(user, "user must not be null")比if (user == null) throw new IllegalArgumentException(...)更简洁、语义更清晰 - 不要用在循环体或高频 getter 内：这不是流程控制，是契约断言；滥用会模糊意图
- 配合
@NonNull注解（如 JetBrains 的）能在 IDE 里提前标黄，但注解不运行时生效——requireNonNull()才是真实防线
String.equals() 调用顺序不能错
看似 trivial，却是线上最常复现的 NPE 场景之一：你永远不知道传进来的 String 是不是 null。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 错：
unknownStr.equals("fixed")——unknownStr为null时直接崩 - 对：
"fixed".equals(unknownStr)—— 安全，返回false - 同理：
Objects.equals(a, b)可替代所有可能含null的等值比较，无需判空
Optional 只能用于返回值，不能塞进字段或参数
Optional 的设计目标不是消灭 null，而是让“可能为空”变成类型系统的一部分。用错地方反而增加风险。
- 合理：
Optional<user> findUser(Long id)</user>—— 强制调用方处理“查不到”的分支 - 反模式：
private Optional<string> name;</string>或void process(Optional<user> user)</user>—— GC 开销上升、序列化出问题、IDE 提示混乱 - 永远避免
optional.get()：它和裸解引用一样危险；优先用orElse()、map()、ifPresent()
集合与数组返回值必须非 null
返回 null 集合是给调用方埋雷。没人想在每次 for 循环前写 if (list != null)。
- 永远用
Collections.emptyList()、Collections.emptySet()、new ArrayList()替代return null - 数组同理：
return new String[0]比return null安全得多 - Stream 操作中记得加
.filter(Objects::nonNull)，尤其在map()后可能产出null元素时
真正难的不是写 if (x != null)，而是判断“这里到底该不该为 null”。契约模糊的地方，NPE 就会在某个凌晨三点准时出现。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
