Optional仅适用于明确表达“有或无”语义的返回值，禁用于字段、参数、集合；避免isPresent()+get()反模式，须用map/filter/orElse等声明式操作，且不可与null混用。
Optional 不是用来包装所有可能为 null 的返回值的
很多人把 Optional 当成“防空指针银弹”，一看到方法可能返回 null 就立刻改成返回 Optional<T>。这反而破坏了语义——比如 Map.get(key) 本就明确表示“查不到就返回 null”，强行包装成 Optional.ofNullable(map.get(key)) 只是增加冗余，还让调用方误以为这是“业务上可选”的结果，而非“查找失败”这种确定性行为。
真正适合用 Optional 的场景是：方法**本意就是表达“有或没有”这一语义**，例如：
-
findUserById(Long id)—— 用户可能不存在，不是异常，是正常业务分支 -
getPreferredLocale()—— 用户没设偏好，就真的“无”
而像 toString()、getValue()、getConfig().getTimeout() 这类访问器方法，如果底层可能为 null，应该先修复源头（比如初始化默认值、校验构造参数），而不是用 Optional 掩盖问题。
别在字段、参数、集合里存 Optional
Optional 是**不可序列化的容器类，设计初衷仅用于方法返回值**。把它用作字段或方法参数，会带来一堆麻烦：
立即学习“Java免费学习笔记（深入）”；
- 字段声明为
private Optional<String> name;→ JSON 序列化（如 Jackson）默认不支持，需额外配置；Hibernate/JPA 不支持映射；调试时多一层嵌套，看值要点开两次 - 方法参数写成
void process(Optional<Order> order)→ 调用方必须构造Optional，丧失直觉；无法区分“传了空 Optional”和“根本没传” - 集合里存
List<Optional<User>>→ 实际等于List<User>加了一层噪音，过滤/遍历时要反复filter(Optional::isPresent).map(Optional::get)，代码更啰嗦且性能略差
如果真需要表达“集合中某些元素可能缺失”，应使用 Stream<User> 配合 filter(Objects::nonNull)，或直接用 List<User> 并接受 null 元素（但需文档说明）。
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
避免 isPresent() + get() 这种反模式
这是最常被吐槽的写法，本质是把 Optional 当成了带 if (x != null) 的语法糖：
if (optionalUser.isPresent()) {
User user = optionalUser.get(); // 危险！get() 在 isPresent() 为 false 时抛 NoSuchElementException
return user.getName();
} else {
return "Anonymous";
}
正确做法是用声明式操作，把逻辑“描述出来”，而不是“手动控制流程”：
- 取值或默认：
optionalUser.map(User::getName).orElse("Anonymous") - 计算后返回 Optional：
optionalUser.filter(u -> u.isActive()).map(User::getEmail) - 链式处理（避免嵌套）：
userService.findById(id).flatMap(u -> addressService.findByUserId(u.getId()))
注意：orElseGet() 比 orElse() 更安全——前者只在 Optional 为空时才执行 Supplier，后者会立即计算默认值，哪怕 Optional 有值也白跑一次。
Optional.empty() 和 null 的边界必须清晰
一个常见陷阱是：方法返回 Optional.empty()，但调用方仍用 == null 判断，导致空指针漏过检测：
Optional<String> result = findConfigValue("timeout");
if (result == null) { // ❌ 永远为 false！Optional.empty() 不是 null
return 30;
}
return result.orElse(30); // ✅ 正确
另一个问题是混淆“空 Optional”和“Optional 包装了 null”：
-
Optional.of(null)→ 直接抛NullPointerException，禁止这样用 -
Optional.ofNullable(null)→ 返回Optional.empty()，安全 -
Optional.ofNullable(someString)→ 如果someString是null，结果仍是empty()；如果不是，才包装它
所以只要用了 Optional，就必须彻底放弃对 null 的显式检查，所有分支都走 map/filter/orElse 等 API。否则不如不用。
