Optional的核心目的是明确表达值可能不存在的语义并强制处理空值，而非简单包装防NPE；应仅在查找、解析等天然可能无结果的场景返回，避免用于字段、参数或滥用get()。
用 Optional 的核心目的不是“包装一下就安全了”，而是**明确表达值可能不存在的语义，并强制调用方主动处理空值场景**。滥用 Optional（比如作为方法返回值却仍调用 get()）反而掩盖问题，甚至引发更隐蔽的 NoSuchElementException。
只在“有/无”是业务语义的一部分时返回 Optional
适合返回 Optional 的典型场景：查找（findById、findByName）、解析（parse(String)）、计算可能无解的结果（max()、findFirst()）。这些操作天然具有“可能找不到”的含义。
不适合的场景：
- 实体类的字段（如
private Optional<string> name;</string>）——破坏封装，增加序列化和持久化负担； - 构造函数参数或 setter 参数——调用方无法直观理解是否必须传值；
- 所有 getter 方法都加
Optional——把简单非空字段过度包装，徒增噪音。
绝不调用 get()，优先使用 orElse / orElseGet / orElseThrow
get() 是 Optional 最危险的方法：它假设值一定存在，一旦为空立刻抛 NoSuchElementException，这和直接解引用 null 几乎等价，只是异常类型不同。
正确做法是根据上下文选择替代方案：
- 提供默认值：用
orElse("default")（适用于常量）或orElseGet(() -> computeDefault())（避免不必要计算）； - 抛出有意义的业务异常：用
orElseThrow(() -> new UserNotFoundException("id: " + id))； - 继续链式处理：配合
map()、flatMap()、filter()做条件转换，保持“空值传播”逻辑清晰。
谨慎使用 Optional 作为方法参数或集合元素
Optional 不是为入参设计的。接收 Optional<String> 的方法会让调用方困惑：“我该传 Optional.of("x") 还是 Optional.empty()？还是直接传 "x"？”——语义模糊，且调用方可能误传 null 导致 NullPointerException。
同理，不要把 Optional 放进 List 或 Map。集合本身已具备“可空”能力（如 list.get(i) 可能为 null），再套一层 Optional 只会增加嵌套判断（optionalList.get(0).map(...).orElse(...)），降低可读性。
与 Stream 和现代 API 协同使用效果更佳
Optional 和 Stream 天然契合：stream.findFirst()、stream.max() 等返回 Optional，可直接链式处理：
users.stream()
.filter(u -> u.isActive())
.sorted(comparing(User::getScore).reversed())
.findFirst()
.map(User::getName)
.orElse("No top user");
也推荐优先使用 JDK 8+ 新增的空值安全方法，如 Objects.requireNonNull()、Map.getOrDefault()、Collection.stream().findFirst().orElse(null)，它们比手动判空更简洁，且不引入额外包装。
