Optional 不能自动消除 NPE，仅显式处理可能为 null 的返回值；应仅用于方法返回值（如 findFirst、get），禁用于字段、集合元素和入参；orElse 立即求值默认值，orElseGet 延迟执行。
Optional 不能自动消除 NPE，它只帮你显式地处理可能为 null 的值；滥用或误用反而会让 NPE 更隐蔽、更难调试。
什么时候该用 Optional 而不是直接判空？
Java 的 Optional 设计初衷是作为「方法返回值」的容器，表示“这个结果可能不存在”，而不是用来包装任意变量或字段。它不适用于：
-
Optional字段（如private Optional<string> name;</string>）——序列化、反射、内存开销都成问题 - 集合元素（如
List<optional>></optional>）——语义混乱，应过滤后存非空值 - 入参（如
void process(Optional<string> s)</string>）——调用方仍可传null，失去意义
典型合理场景：工厂方法、查找方法、解析方法的返回值，比如 Stream.findFirst()、Map.get() 包装后的结果。
Optional.orElse() 和 Optional.orElseGet() 的关键区别
两者都用于提供默认值，但执行时机不同，直接影响性能和副作用：
立即学习“Java免费学习笔记（深入）”；
-
orElse(T other)：无论Optional是否有值，other表达式都会立即求值（可能触发无谓计算或异常） -
orElseGet(Supplier extends T> supplier)：仅当值为空时才调用supplier.get()，延迟执行，推荐用于耗时/有副作用的操作
示例：
Optional<String> opt = Optional.empty(); String s1 = opt.orElse(expensiveOperation()); // 立即执行，即使没用到 String s2 = opt.orElseGet(() -> expensiveOperation()); // 只在需要时执行
别用 Optional.get()，除非你 100% 确认非空
get() 是 Optional 最危险的方法——它会在空值时直接抛 NoSuchElementException，这和 NPE 一样属于运行时崩溃，且堆栈更难追溯。
- 永远不要写
opt.get().toString()这类裸调用 - 替代方案优先级：先用
ifPresent()处理存在逻辑；需转换用map()；需默认值用orElse()/orElseGet()；需抛定制异常用orElseThrow() - 如果业务上“必须有值”，那应该在上游校验并抛
IllegalArgumentException，而不是靠get()把问题推给下游
和 Spring、Jackson 等框架一起用时的坑
Optional 不是“万能 null 替代品”，很多主流库对它的支持有限或反直觉：
- Spring MVC 的
@RequestParam和@PathVariable支持Optional作为参数类型，但@RequestBody不支持——JSON 反序列化不会自动转成Optional字段 - Jackson 默认忽略
Optional字段（不序列化也不反序列化），需显式注册OptionalModule，且反序列化 null JSON 值时行为不统一 - Lombok 的
@Data会为Optional字段生成 getter/setter，但 setter 接收null会导致Optional.of(null)抛异常
实际项目中，更稳妥的做法是：DTO 层用原始类型 + 文档约定“可选”，服务层再按需包装为 Optional 返回。
最常被忽略的一点：Optional 的存在本身是一种契约信号——它告诉调用方“这里可能没有值”，但如果团队成员不理解这点，随意链式调用 .map(...).orElse(...) 而不考虑业务含义，就只是把 null 检查换了一种写法而已。
