optional.get() 总抛 nosuchelementexception，因未检查值存在就直接调用；应优先用 orelse()、orelseget() 或 orelsethrow()，避免 ispresent() + get() 模式，且不可滥用 optional 替代简单判空。
Optional.get() 为什么总抛 NoSuchElementException
直接调用 get() 前没确认值存在，是踩坑最频繁的操作。它不判断、不提示、不兜底，就像伸手去摸黑盒里有没有东西，摸不到就直接扔异常。
常见于从 Map 或 Stream 中取值后盲目调用：optional.get() —— 实际上绝大多数场景根本不需要 get()。
- 要用
orElse()或orElseGet()提供默认值 - 要抛自定义异常时，用
orElseThrow(() -> new BusinessException("用户不存在"))，而不是先isPresent()再get() -
orElseGet()比orElse()更安全：后者会立即计算默认值（哪怕 Optional 有值），前者只在为空时才执行 Supplier
链式调用中嵌套 null 判断被 Optional 掩盖
比如 user.getAddress().getCity() 这种写法，即使外层用了 Optional.ofNullable(user)，中间的 getAddress() 仍可能返回 null，导致 NPE —— Optional 不会自动穿透多层对象。
正确做法是每层都显式包装：
立即学习“Java免费学习笔记（深入）”；
Optional.ofNullable(user)
.map(User::getAddress)
.map(Address::getCity)
.orElse("未知城市");
-
map()是安全的“穿透”操作，返回仍是Optional；flatMap()适用于返回Optional的函数（比如数据库查询方法本身返回Optional） - 别把
Optional当成万能 null 消除器，它只保护你调用它的那一层 - 如果底层方法没法改（比如老接口返回 null），就得在每一步手动
ofNullable，不能偷懒
把 Optional 当返回类型暴露给 public API
对外提供方法时返回 Optional<string></string>，等于告诉调用方“这个值可能没有”，但实际语义常不匹配：比如 findById(Long id) 返回 Optional<user></user> 合理，但 getName() 返回 Optional<string></string> 就可疑——名字不该是可选的。
- 仅在业务语义上“天然可空”且调用方需要区分“未找到”和“找到但为空字符串”时，才考虑返回
Optional - 避免在 DTO、VO、JSON 序列化字段中用
Optional—— Jackson 默认不支持，会序列化成空对象或报错 - Spring Data JPA 的
findById()返回Optional是特例，因为它是基础设施层，且明确表达“查无此记录”这一状态
用 Optional 替代 if-else 分支反而让逻辑更难读
比如一段本该直白的校验逻辑：
if (user == null || user.getAge() < 18) {
throw new IllegalArgumentException("用户未登录或未成年");
}
硬改成：
Optional.ofNullable(user)
.filter(u -> u.getAge() >= 18)
.orElseThrow(() -> new IllegalArgumentException("用户未登录或未成年"));
这就本末倒置了。Optional 的优势在数据流处理（filter/map/flatMap 链式组合），不在替代简单条件分支。
- 单层判空 + 抛异常，用三元运算符或普通 if 更清晰
- 涉及多个条件组合、嵌套查询、默认值 fallback 时，Optional 才真正减少嵌套层级
- 团队里有人不熟悉
flatMap和orElseGet的执行时机，强行推广容易引入隐蔽 bug
Optional 不是语法糖，是建模工具。用错地方，比写个 if 还容易漏掉边界情况。
