Optional仅应用于方法返回值以明确表达可能无结果，不可用于字段或参数；应使用ofNullable()处理可能为null的值，避免isPresent()+get()链式调用，注意其不可序列化及框架兼容性限制。
Optional 不是用来包装所有可能为 null 的变量的，它只该出现在方法返回值里——这是避免空指针最有效、也最容易被用错的地方。
什么时候该用 Optional？只在方法返回值中出现
Java 8 引入 Optional 的本意，是让 API 设计者明确表达“这个方法可能不返回结果”。它不是 null 的替代品，更不是给字段或参数加一层包装的工具。
- ✅ 正确：把
findUserById(int id)的返回类型从User改成Optional<User> - ❌ 错误：把类字段声明为
private Optional<String> name;，或者把入参写成process(Optional<Order> order) - ❌ 更错：用
Optional.of(null)——这会立刻抛出NullPointerException，和你原本想避免的问题一模一样
Optional 的三种构造方式差异很大
选错构造方法，轻则逻辑绕弯，重则掩盖真实问题。
-
Optional.of(value)：value 绝对不能为null，否则运行时报NullPointerException -
Optional.ofNullable(value)：唯一安全的入口，null进去 → 空Optional出来 -
Optional.empty()：手动创建空值，适合提前退出或兜底场景，比如if (ids.isEmpty()) return Optional.empty();
常见错误现象：Optional.of(getUserFromCache(id)) 中 getUserFromCache 返回 null，直接炸掉——这里必须用 ofNullable。
立即学习“Java免费学习笔记（深入）”；
别用 isPresent() + get() 写成 if-else 套壳
这种写法不仅没消除 null 风险（get() 本身可能抛异常），还让代码更啰嗦、更难读。
- ❌ 避免：
if (userOpt.isPresent()) { return userOpt.get().getName(); } else { return "anonymous"; } - ✅ 推荐：
userOpt.map(User::getName).orElse("anonymous") - ✅ 或更明确：
userOpt.orElseGet(() -> createDefaultUser()).getName()
性能影响很小，但语义清晰度差别巨大：前者是“我手动检查再取值”，后者是“我声明一个转换+默认策略”。
和 Stream、第三方库交互时容易忽略兼容性
Optional 是不可序列化的，且很多老框架（比如早期 MyBatis、Jackson 2.8 之前）根本不认它。直接当 DTO 字段用，序列化会失败，JSON 返回可能是空对象或报错。
- MyBatis：映射
Optional<String>字段会返回null，而不是空Optional；建议只在 service 层返回，mapper 层保持原始类型 - Jackson：需显式注册
OptionalModule，否则@ResponseBody返回 JSON 时字段消失 - Lombok：
@Data自动生成toString()和equals()，但对Optional字段效果不可靠，容易引发误判
真正复杂的地方不在语法，而在于边界——它只该在“调用方需要决定如何处理缺失值”的那一层存在，再往里（DAO）、再往外（HTTP 响应体），往往都得退回到原始类型。
