Optional 的本意是显式表达“可能为空”的语义，提升 API 可读性与安全性；应正确使用 ofNullable、flatMap 等方法，避免滥用为包装器、字段或参数，并注意性能与序列化限制。
用 Optional 替代 null 判空，不是为了炫技，而是把“可能为空”显式写进类型里
Java 8 引入 Optional 的本意，是让方法签名自己说话：这个返回值“可能没有”，而不是靠文档、注释或运气去猜。它不解决 null 的根源问题，但能把你写 if (obj != null) 的地方，从散落各处的防御性检查，收束成可组合、可推导的链式表达。
常见错误现象：
— 把 Optional 当包装器滥用，比如 new Optional(obj)（禁止！必须用 Optional.of() 或 Optional.ofNullable()）
— 在 DAO 层直接返回 Optional<user></user>，却没同步改掉 MyBatis 的 @Select 方法签名，导致运行时报 NullPointerException（MyBatis 默认不支持 Optional 返回值）
— 调用 optional.get() 前不检查，等于换种方式写 obj.toString()
-
Optional.of(value)：value 绝对不能为null，否则抛NullPointerException -
Optional.ofNullable(value)：唯一安全的构造方式，null进 → 空Optional出 -
Optional.empty()：显式构造空值，比null更具语义
链式调用时怎么避免 Optional 嵌套爆炸（Optional<optional>></optional>）
嵌套 Optional 是典型误用信号，说明你在用函数式语法写命令式逻辑。比如连续调用两个可能返回 Optional 的方法，直接 .map() 就会套娃。
正确做法是用 .flatMap() 拆平一层：
立即学习“Java免费学习笔记（深入）”；
Optional<User> userOpt = getUserById(123); Optional<Address> addressOpt = userOpt.flatMap(User::getAddress); // ✅ 不是 .map()
使用场景：
— 多级属性访问（user.getAddress().getCity().getName() → 改成链式 flatMap + map）
— 数据库查询后做二次过滤（findUser().filter(...).flatMap(this::loadProfile)）
-
.map()：适用于转换值本身，返回普通对象 → 自动包进新Optional -
.flatMap()：适用于返回另一个Optional的函数，自动展平 - 别在
.filter()里写副作用逻辑（如打日志），它只该做纯判断
Optional 不能替代所有判空，哪些地方硬上反而更糟
它不适合当“万能空值容器”塞进集合、字段、参数或 JSON 序列化流程里。
性能影响：
— 每次 Optional 实例化都有对象开销，高频调用（如循环内、日志打印）会放大 GC 压力
— Jackson 默认不序列化 Optional，需配 JacksonJsr310Module 或自定义 Serializer，否则字段直接消失
- 不要作为类字段：
private Optional<string> name;</string>— 违反 JavaBean 规范，反射、ORM、序列化全崩 - 不要用于方法参数：
void process(Optional<string> input)</string>— 调用方还得构造Optional，徒增噪声 - 集合元素别用
Optional：List<optional>></optional>— 语义混乱，应改为List<user></user>+ 文档说明允许空元素 - DAO 方法返回
Optional仅限单条查询；List查询、分页、统计等一律不用
和 Lombok 的 @NonNull / @RequiredArgsConstructor 混用时容易踩的坑
Lombok 的空值检查发生在编译期或构造阶段，而 Optional 是运行时语义，两者不在一个维度。强行混用会导致预期外的行为。
常见错误现象：
— @RequiredArgsConstructor + private final Optional<string> field;</string> → 构造器强制传 Optional，但调用方大概率想传 "abc"，结果写成 new Foo(Optional.of("abc"))，冗余且易错
— @NonNull 标在 Optional 参数上，等于要求传非空的 Optional 实例，但空 Optional 本身就是合法值
- 字段用
@NonNull时，类型别选Optional；要校验非空，就用原始类型 + 显式判空 - Lombok 的
@Builder和Optional兼容性差，builder().field(null)会触发 NPE，不如手动写 builder 方法 - 如果真需要构造时防
null，用Objects.requireNonNull()显式写在构造器里，比注解更可控
最常被忽略的一点：Optional 的 equals() 和 hashCode() 行为跟 null 不一致，放进 HashSet 或作为 Map key 时，空 Optional 和 null 不等价，也跟普通对象不等价 — 这种边界情况，调试起来特别费时间。
