Java如何用Optional防空指针异常

Optional不能替代null检查，只是封装判空逻辑；它不阻止传入null，仅强制显式处理空值；正确用法是ofNullable()构造、避免get()前不校验、链式map/flatMap扁平化操作，且仅适用于方法返回值。

Optional 不能替代 null 检查，只是封装了判空逻辑

很多人误以为用了 Optional 就能“自动”避免空指针异常，其实不然。它本身不阻止你传入 null，也不拦截方法调用；它只是一个**容器类**，强制你在解包前显式处理“值可能不存在”的情况。

常见错误是这样写：

Optional<String> opt = Optional.of(null); // 直接抛出 NullPointerException

正确做法是：

• Optional.of(value)：仅当 value 确保非 null 时使用
• Optional.ofNullable(value)：唯一安全的构造方式，value 为 null 时返回 Optional.empty()
• 永远别对 Optional 对象本身调用 .get() 前不检查 .isPresent() 或不用 .orElse() 类方法

链式调用中 map/flatMap 是避免嵌套判空的关键

当你有一串可能为空的对象引用（比如 user.getAddress().getCity().getName()），传统写法要层层判空；用 Optional 配合 map 可以扁平化处理。

区别在于：

• map：适用于返回普通对象的函数，结果自动包装成 Optional；若上游是 empty，整个链短路返回 empty
• flatMap：适用于返回 Optional 的函数，避免嵌套 Optional<Optional<T>>

示例：

Optional<User> userOpt = Optional.ofNullable(user);
String cityName = userOpt
    .map(User::getAddress)
    .map(Address::getCity)
    .map(City::getName)
    .orElse("未知城市");

不要把 Optional 用作字段或方法返回值以外的场景

Optional 被设计为**短期存在、即用即弃**的返回类型，JDK 明确不建议：

• 作为实体类的字段（如 private Optional<String> name;）——序列化、反射、ORM 映射都会出问题
• 作为 @RequestParam 或 @RequestBody 的参数类型（Spring 不支持）
• 在集合中存储（如 List<Optional<T>>）——语义混乱，且增加 GC 压力

它只应在**方法返回值**中表明“这个结果可能没有”，让调用方立刻意识到需要处理缺失情况。

性能与可读性权衡：简单判空不如直接 if，复杂流程才值得用 Optional

对单层判空，比如 if (str != null) { ... }，硬套 Optional.ofNullable(str).map(...).orElse(...) 反而更啰嗦、更慢（对象创建开销）。

真正适合 Optional 的场景是：

• 多个可能为空的中间步骤需要组合（如上面的 user→address→city→name）
• API 设计上想明确表达“无值”是一种合法状态，而非异常
• 配合 Stream 的 filter、findFirst 等操作做声明式处理

记住：Optional 不是银弹。它解决的是“如何优雅表达可选性”，不是“怎么消灭 null”。null 本身没坏，坏的是隐式假设它不为 null。