Optional 不能自动防止空指针异常，它仅提供显式处理 null 的契约机制；误用（如将 null 赋给 Optional 变量或在 null 的 Optional 上调用 get()）反而引发 NullPointerException；get() 抛 NoSuchElementException 而非 NPE，但 optional 本身为 null 时调用 get() 前即触发 NPE；应避免用于字段、参数和集合，仅作可能无结果的方法返回值；orElse 立即求值，orElseGet 延迟执行 Supplier。
Optional 不能自动防止空指针异常，它只提供一种显式处理 null 的契约机制；滥用或误用反而会掩盖问题、引发新的 NullPointerException。
为什么直接调用 get() 依然会抛出空指针异常
Optional.get() 的设计本意是“你已确认值存在”，它内部会检查 isPresent()，若为 false 就抛出 NoSuchElementException——注意，这不是 NullPointerException。但很多人误以为“用了 Optional 就安全了”，于是写成：optional.get().toString()，结果在 optional 本身为 null 时（比如方法返回了 null 而非 Optional.empty()），调用 .get() 前就已触发 NPE。
- 永远不要把
null赋给Optional变量：✅Optional<string> opt = Optional.ofNullable(str);</string>，❌Optional<string> opt = null;</string> - 所有返回
Optional的方法，必须确保返回的是Optional.empty()或Optional.of(...)，绝不能返回null -
get()应仅用于单元测试或逻辑上 100% 确定有值的极少数场景；日常业务中优先用ifPresent()、orElse()、map()
哪些场景不该用 Optional 作方法返回值
Java 官方文档明确指出：Optional 不应作为实体类字段、方法参数或集合元素。它不是为持久化或传输设计的，序列化支持弱，且会让 API 意图模糊。
- ❌
public class User { private Optional<string> name; }</string>—— 字段不应是Optional - ❌
void process(Optional<string> input)</string>—— 方法参数用Optional会迫使调用方包装，丧失语义清晰性 - ❌
List<optional>></optional>—— 集合嵌套Optional是反模式，应过滤掉 null 后用List<integer></integer> - ✅ 正确用途：作为**方法返回值**，表示“计算可能无结果”，如
Stream.findFirst()、Map.get()的封装层
orElse() 和 orElseGet() 的性能与副作用差异
二者都用于提供默认值，但执行时机不同：orElse(T other) 会**立即求值**传入的参数；而 orElseGet(Supplier extends T> other) 是懒加载，在 Optional 为空时才调用 Supplier。
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
- 如果默认值构造代价高（如新建对象、IO、数据库查询），必须用
orElseGet(() -> expensiveOperation()) - 如果默认值是常量或轻量表达式（如
"default"、0），用orElse("default")更简洁 - ⚠️ 错误示例：
opt.orElse(new HeavyObject())—— 即使opt有值，HeavyObject也会被创建
链式调用中 map() 和 flatMap() 的选择依据
当需要对 Optional 内部值做转换，并且转换结果本身也是 Optional（比如查数据库返回 Optional<user></user>，再取其邮箱又返回 Optional<string></string>），必须用 flatMap()；否则会得到 Optional<optional>></optional>，后续操作极易出错。
Optional<User> userOpt = findUser(id); // ❌ 错误：返回 Optional<Optional<String>> Optional<Optional<String>> nested = userOpt.map(User::getEmail); // ✅ 正确：flatMap 展平一层 Optional<String> emailOpt = userOpt.flatMap(user -> user.getEmail());
-
map()适用于转换后返回普通类型（T → R） -
flatMap()适用于转换后返回Optional<r></r>（T → Optional<r></r>） - 嵌套
Optional很难调试，IDE 通常不报错，但运行时get()会抛NoSuchElementException
真正容易被忽略的点在于：Optional 的价值不在“避免 NPE”，而在强制开发者面对“缺失”这一事实——它把隐式的 null 分支，变成显式的类型契约。一旦开始用 get()、把 Optional 当容器塞进字段或参数，就等于退回了 null 地狱的门口。
