为什么引入 Optional？
Java 一直是强类型语言，但在很长一段时间里，对 null 值的处理始终是个短板。开发者经常依赖繁琐的 null 判断语句，甚至有时干脆忘记写检查逻辑，结果导致了可怕的 NullPointerException 异常。因此，Java 8 引入了 Optional，以一种更优雅、安全的方式来表示“值的缺失”。
Optional 的核心思想是以类型安全的方式包装可能为 null 的值。它迫使开发者从一开始就考虑 null 的可能性，而不是让大量 if 条件语句散布在代码中。它改变了思考方式：不再是“这个值是不是 null”，而是“是否存在值”。
这种细微的思维转变能带来更强的设计。Optional 并不能解决所有问题，但它表达意图更清晰，引导代码更少出现运行时意外，行为更可预测。
Optional 的常见误用
并不是所有 Optional 的使用都是有益的，甚至滥用还会带来反效果。一个常见错误是：在实体类或数据模型中，将字段定义为 Optional。起初看似优雅，其实只会浪费内存并增加不必要的包装层，此时使用简单的 nullable 字段反而更合适。
另一个不良做法是将 Optional 用作方法参数。Optional 本来是用于表示“可能为空的返回值”，不是为了传递“可选的输入参数”。这种用法只会让代码阅读者产生困惑，并导致风格不统一。
最危险的误用，是完全忘记了 Optional 的初衷。有人为了避免写 null 判断，把所有值都包装成 Optional。这种行为只是换了一种方式制造“代码冗余”。Optional 的亮点并不在于“无处不在”，而是“用得恰到好处”。
更好的 Optional 创建方式
创建 Optional 很简单，只需调用 Optional.of(value)，但前提是这个值保证非 null。如果你尝试用 null 调用 Optional.of()，会直接抛出异常——这和避免 NPE 的初衷相悖。这时就应该使用 Optional.ofNullable(value)，它能优雅地接受 null 并返回 Optional.empty()。
开发者应避免轻率地返回 Optional.empty()，除非确实要表达“值缺失”。更好的做法是：代码尽量返回有意义的值，在可能缺失的地方明确使用 Optional 来做“提示标志”。
理解什么时候创建 Optional、如何优雅地创建它，有助于提高代码可读性，同时向调用者明确表达意图。
合理使用 isPresent 和 ifPresent
虽然 isPresent() 是许多开发者的第一选择，但过度使用它，只是把 Optional 变成了“高级版 null 判断”。典型的冗余代码如下：
java
CopyEdit
if (optional.isPresent()) {
optional.get();
}
这完全违背了 Optional 的设计初衷。
相反，ifPresent(Consumer) 提供了一种更安全、更清晰的写法。当值存在时执行操作，不存在时什么也不做。它让代码更流畅、可读性更强，并且天生防御空值。
学会从 isPresent 转向 ifPresent，是打造直观 API 的关键一步，也能减少冗余逻辑，让代码更紧凑、更易懂。
使用 map 和 flatMap 实现转换
Optional 在配合 map 和 flatMap 使用时，威力十足。这些方法可以在不写 null 判断的前提下完成链式转换。这是一种思维方式的改变：当值存在时处理，当值缺失时自动跳过。
比如，将包含用户对象的 Optional 转换为用户名，可以用 map 优雅实现，避免了重复的 if 判断；而 flatMap 更适合处理嵌套 Optional 的场景，能把嵌套结构平滑展开。
这种模式鼓励在 Java 中使用函数式编程风格。虽然初看略显陌生，特别是对习惯命令式编程的开发者而言，但这种风格能用更少代码完成更多逻辑。
orElse vs orElseGet：选择正确的默认值方式
orElse 和 orElseGet 看似类似，其实区别很大。虽然两者都在 Optional 为空时提供备用值，但 orElse 总是提前计算参数，即使最终没用到，这可能带来性能损耗或副作用。
而 orElseGet 接收一个 Supplier，仅在需要时才会执行计算。如果默认值涉及计算或访问资源，orElseGet 几乎总是更好的选择。
理解这两个方法的差异，能有效防止潜在的“静默 bug”，提高代码的可控性和执行效率。
在 Stream 和方法链中的使用
在使用 Java Stream 时，Optional 可以无缝衔接。例如，findFirst() 和 findAny() 返回的都是 Optional，天然支持“无值”的场景，让 Stream 操作流程以一种安全方式结束。
将 Optional 与 Stream 结合使用，可构建出优雅的链式方法调用。无论是过滤、映射还是聚合数据，Optional 都能作为终点明确地表达值是否存在。
这种写法既符合函数式风格，又保持了面向对象的表达能力。它鼓励写出更小、更易测试、可组合性强的方法。
在公共 API 中避免滥用
虽然 Optional 很有用，但应该只在合理场景中使用。特别是在公共 API 中，如果滥用 Optional，反而会让调用者感到困惑，增加对接成本。
如果每个方法都返回 Optional，即使值永远不会缺失，调用方仍必须多此一举地进行检查。这会导致防御性编码泛滥，影响开发效率并增加心智负担。
好的 API 设计是有选择地使用 Optional，在缺失是预期结果的场景中使用它。开发者应该问自己：“这个值是否可能真的缺失？是否应该用 Optional 表达？”如果不是，直接返回值或抛出异常才是更合适的做法。
Optional 如何提升代码安全性
Optional 最大的优势在于它能“重塑开发者的思维方式”。每次在返回类型中使用 Optional，其实是在告诉调用者：“你需要考虑值不存在的情况。”
这种意识转变能避免许多常见 bug。它让方法的契约更清晰，也让代码自带文档性质，引导使用者以正确方式调用。
当正确使用时，Optional 不仅仅是一个工具，它会逐渐变成一种习惯——一种思考更细致、写代码更可靠的习惯。
用 Optional 写出更清晰的 API
Optional 的长远价值在于它能提升 API 的表达力。那些设计良好的方法，当返回 Optional 时，能够清楚地传达“值可能不存在”。
开发者在优化库或服务接口时，可用 Optional 来表达“缺失”这一概念，而不必动辄抛异常。这是一种更温和、更灵活的方式，把控制权交还给调用方，同时又不失结构化设计。
随着时间推移，正确使用 Optional 的项目，会自然而然形成一种“可预测且精准”的接口风格。这正是开发者最希望使用和维护的代码。