Java Optional 好用吗

Java Optional 好不好用，得看场景。
一句话总结：它是一个“防 null 的设计工具”，不是“替代所有 null 的银弹”。

一、Optional 好用在哪？

1️⃣ 明确表达“可能为空”

比直接返回 null 更清晰：

// 不推荐
User getUserById(Long id) { ... } // 可能返回 null

// 推荐
Optional<User> getUserById(Long id) { ... }

调用方一眼就知道：这个值可能不存在。

2️⃣ 避免深层 null 判断

以前：

if (user != null) {
    Address addr = user.getAddress();
    if (addr != null) {
        return addr.getCity();
    }
}
return "UNKNOWN";

用 Optional：

return user
    .flatMap(User::getAddress)
    .map(Address::getCity)
    .orElse("UNKNOWN");

链式调用更清爽，逻辑更线性。

3️⃣ 强制处理“空”的情况

Optional<User> userOpt = getUser();
User user = userOpt.orElseThrow(() -> new RuntimeException("用户不存在"));

比忘了判 null 直接 NPE 好太多了。

二、Optional 不好用 / 容易误用的地方

❌ 1. 不要用在实体类字段

class User {
    private Optional<Address> address; // ❌ 不推荐
}

问题：

• 序列化麻烦
• 增加对象开销
• JPA / JSON 不友好

✅ 字段就用普通类型 + 业务约束

❌ 2. 不要当“集合”或“参数”用

void process(Optional<User> user) { ... } // ❌ 不好

原因：

• 调用方还得包一层
• 不如直接重载或判空

✅ 方法参数避免 Optional

❌ 3. isPresent + get 是“退化写法”

if (opt.isPresent()) {
    doSomething(opt.get());
}

这和 if (x != null) 没区别，甚至更啰嗦。

✅ 用 map / ifPresent / orElse

三、Optional 正确的使用姿势

✅ 适合：

• 方法返回值（尤其是查询类）
• 流式处理（Stream + Optional）
• 明确“可能无结果”的语义

✅ 不适合：

• 类字段
• 方法参数
• 集合元素（用空集合更好）

四、真实项目里的感受

Optional 不是“让代码变少”，而是“让空值变得可控”。

用得好：

• 接口更清晰
• NPE 少很多
• 逻辑更函数式

用不好：

• 代码更绕
• 性能略差
• 维护成本上升

如果你愿意，我可以：

• 给你一套 Optional 使用规范（公司级）
• 或对比 Kotlin null safety vs Java Optional
• 或帮你 把老代码重构为 Optional 风格

你更想看哪个？