链式调用防空指针技巧解析

Optional 并非空指针异常的“银弹”，它仅以函数式方式封装判空逻辑，且只对明确返回 Optional 类型的方法链有效；误用 `Optional.of(null)` 会立即触发 NPE，正确做法是从方法签名层面主动返回 `Optional`，并统一使用 `ofNullable()` 处理外部不确定来源的数据；链式调用中必须区分 `map`（处理非 Optional 返回值）与 `flatMap`（展平嵌套 Optional），否则极易因类型错配导致运行时错误；更关键的是，真正的空安全应前移至定义侧——借助 Lombok `@NonNull`、IDE 空值检查和严谨的接口契约，而非依赖后期繁复的 Optional 堆砌，否则不仅无法根治问题，还可能掩盖 null 的真实来源，让调试和日志分析陷入误区。

Optional 链式调用不能“彻底消除”空指针判空

直接说结论：Optional 本身不是空安全的银弹，链式调用（如 map、flatMap、orElse）只是把显式 if (x != null) 搬到了函数式表达里，底层仍依赖判空逻辑。它不消除判空，而是封装判空——且只对 Optional 类型生效，对原始引用（比如方法返回 null 而非 Optional）完全无效。

常见误用是：把一个可能为 null 的对象强行包装成 Optional.of(obj)，结果一运行就抛 NullPointerException ——因为 Optional.of 明确拒绝 null。

• 正确起点是：方法签名主动返回 Optional，而非 T
• 错误起点是：外部把 null 塞进 Optional.of，或对未校验的字段直接调用 get()
• Optional 链式调用只有在整条链都基于 Optional 构建时才“看起来”无判空，一旦中间某步返回原始引用，链就断了

什么时候该用 Optional.empty() 而不是 Optional.ofNullable()

Optional.ofNullable() 是唯一安全接收 null 的工厂方法；Optional.of() 仅用于你 100% 确认非空的场景。但很多人混淆两者用途，导致 NPE 出现在构造阶段而非业务逻辑中。

典型反例：

Optional<User> userOpt = Optional.of(getUserFromDb(id)); // getUserFromDb 可能返回 null → NPE

应改为：

Optional<User> userOpt = Optional.ofNullable(getUserFromDb(id));

• 所有从外部系统、数据库、HTTP 响应等获取的值，一律用 ofNullable
• of 只适合内部已做判空后的确定值，例如 Optional.of(Objects.requireNonNull(user))
• 不要在流操作中对 Optional 再套一层 ofNullable：比如 list.stream().map(Optional::ofNullable).map(Optional::get) ——这等于绕了一圈又把 null 拿回来

flatMap 是 Optional 链式调用不崩的关键

当你需要从一个 Optional 中提取另一个可能为空的值（比如 A.getName() 返回 String，而你想再取 name.length()），必须用 flatMap，而不是 map。否则会得到 Optional>，后续调用 get() 或 orElse 就会出错。

Optional<User> userOpt = Optional.ofNullable(findUser(123));
// ❌ 错误：map 返回 Optional<Optional<String>>
Optional<Optional<String>> nameOptOpt = userOpt.map(u -> Optional.ofNullable(u.getName()));

// ✅ 正确：flatMap 展平一层
Optional<String> nameOpt = userOpt.flatMap(u -> Optional.ofNullable(u.getName()));