Optional.map()用于转换值不嵌套，flatMap()用于扁平化Optional；orElse()立即执行，orElseGet()/orElseThrow()懒加载；Stream中用flatMap(Optional::stream)替代filter+get；字段禁用Optional，仅限返回值。
Optional.map() 和 Optional.flatMap() 到底该用哪个？
map() 适合对 Optional<t></t> 内部值做「转换但不嵌套」的操作，比如把 String 转成 Integer；flatMap() 则用于返回另一个 Optional 的场景，避免 Optional<optional>></optional> 套娃。
常见错误现象：
- 用
map()调用了返回Optional的方法（比如findById()），结果得到Optional<optional>></optional>，后续get()直接抛NoSuchElementException - 把
flatMap()当成“更高级的map()”滥用，其实它只是扁平化一层包装
使用场景举例：
- 查用户 → 查其部门 → 查部门负责人：中间任意一环可能为空，用
flatMap()串起来最自然 - 字符串非空就转大写：用
map()就够了，toUpperCase()返回的是String，不是Optional<string></string>
实操建议：
- map() 的 lambda 参数必须返回非 Optional 类型
- flatMap() 的 lambda 必须返回 Optional 类型，否则编译不过
- 如果你不确定返回值类型，先写 flatMap()，IDE 会立刻报错提醒你是否多包了一层 Optional
Optional.orElse()、orElseGet() 和 orElseThrow() 的性能与副作用差异
这三个方法都在 Optional 为空时提供兜底逻辑，但执行时机和开销完全不同。
立即学习“Java免费学习笔记（深入）”；
orElse() 无论 Optional 是否有值，都会立即执行传入的对象构造或方法调用；orElseGet() 是懒加载——只在为空时才调用 Supplier；orElseThrow() 同理懒加载，且抛异常。
常见错误现象：
- 用
orElse(new ExpensiveObject())导致每次调用都创建对象，哪怕Optional有值 - 在
orElse()里写日志或 DB 查询，结果日志总多打一次、查询总多跑一回
实操建议：
- 所有带副作用或耗资源的操作（如 new 对象、IO、计算），一律用 orElseGet(() -> ...)
- 明确需要抛异常时，优先用 orElseThrow(() -> new XxxException(...))，比 get() + if (!isPresent()) 更简洁安全
- orElse(null) 是反模式，暴露空指针风险，应改用 orElseGet(() -> null) 或直接重构为不返回 null
Stream.filter() 遇到 Optional 该怎么写才不踩坑？
Stream<optional>></optional> 是常见但危险的结构。直接 filter(Optional::isPresent) 只是筛出非空容器，还得 map(Optional::get) 才能拿到真实数据——但 get() 在并发或误操作下仍有风险。
更稳妥的做法是先 flatMap(Optional::stream)，把 Stream<optional>></optional> 转成 Stream<t></t>，天然过滤掉空值，且无 get() 调用。
常见错误现象：
-
stream.map(...).filter(Optional::isPresent).map(Optional::get)—— 多余的两步，还藏get()风险 - 在
filter()里写optional -> optional != null && optional.isPresent()，其实Optional永远不为null，白写
实操建议：
- 确保上游不产生 null 的 Optional（比如别用 Optional.of(null)）
- 用 flatMap(Optional::stream) 替代手动判空 + 解包，语义清晰、零风险
- 如果必须保留 Optional 结构（如做聚合统计），那就用 filter(Optional::isPresent) + map(Optional::get)，但务必确认上游绝对可靠
Optional 作为字段或方法返回值时的真实约束力
Optional 不是银弹。它不能阻止别人调用 get()，也不能让 IDE 或 JVM 自动检查空值，更不能替代文档和契约。
很多人以为加了 Optional 就等于“强制判空”，实际只要对方写 optional.get()，照样崩；而且序列化、JSON 库（如 Jackson）、ORM（如 JPA）对 Optional 支持参差不齐，容易引发运行时异常或静默丢值。
常见错误现象：
- DTO 中用
Optional<string> name</string>，结果 JSON 反序列化失败，报Cannot construct instance of java.util.Optional - JPA 实体字段声明为
Optional<long> id</long>，Hibernate 直接报org.hibernate.MappingException
实操建议：
- 方法返回值可用 Optional，但**字段不要用**——JPA/Hibernate/JSON 默认都不认
- Spring MVC 接口返回 Optional 是安全的（Jackson 2.9+ 支持），但前端得配合处理，否则可能收不到字段
- 如果团队没统一约定，别指望靠 Optional 让所有人自动判空；该加注释加注释，该写单元测试写单元测试
- 最关键的一点：Optional 的存在本身就是在说“这个值业务上可能不存在”，如果它本该必有，就别包 Optional，那只是自欺欺人
