java中用optional替代null的核心是通过类型系统显式表达“可能无值”语义，强制调用方在编译期处理空值，仅适用于返回值，不应用于参数或字段，并配合map/flatmap等实现声明式空值处理。
Java 中用 Optional 替代 null 作为方法返回值，核心不是“包装一下 null”，而是通过类型系统显式表达“可能无值”这一语义，让调用方无法忽略空值处理，从而在编译期就约束契约。
明确声明“可选性”，避免隐式 null 契约
传统返回 null 是弱契约：调用方需查文档或试错才知道是否可能为空；而返回 Optional<t></t> 是强契约：类型本身即说明“这个结果不一定存在”。这迫使调用方主动处理 isPresent()、orElse() 等分支，而不是直接调用方法后 NPE。
- ✅ 正确：
public Optional<user> findUserById(Long id) { ... }</user> - ❌ 不推荐：
public User findUserById(Long id) { ... } // 文档写“可能返回 null”，但编译器不管
只用于返回值，不作为参数或字段
Optional 是为“函数式返回语义”设计的容器，不是通用空值替代品。把它当参数传入或存为类字段，反而增加复杂度且违背初衷。
- ❌ 避免：
public void process(Optional<string> name) {...}</string>—— 调用方仍得先get()或判空，没解决根本问题 - ❌ 避免：
private Optional<date> lastLogin;</date>—— 序列化、调试、ORM 映射都易出问题 - ✅ 推荐：参数用普通类型，内部逻辑用
Optional.ofNullable(...)封装返回
配合链式操作，把“空值处理”变成声明式流程
利用 map()、flatMap()、filter() 等方法，把原本嵌套 if-null-check 的命令式代码，转为可读性强、不易漏分支的流式表达。
例如查用户→取邮箱→转小写：
- 传统写法（易漏判空）：
if (user != null && user.getEmail() != null) return user.getEmail().toLowerCase(); - Optional 写法（自动短路）：
return findUserById(id).map(User::getEmail).map(String::toLowerCase).orElse("unknown");
谨慎使用 orElseGet / orElseThrow，避免副作用和掩盖问题
orElse(T) 会立即计算默认值，哪怕 Optional 有值；而 orElseGet(Supplier) 是惰性求值，更安全。对“无值即错误”的场景，优先用 orElseThrow() 显式抛异常，而非静默 fallback。
- ⚠️ 少用：
optional.orElse(expensiveDefault())—— 即使有值也会执行expensiveDefault() - ✅ 推荐：
optional.orElseGet(() -> computeDefault()) - ✅ 推荐：
optional.orElseThrow(() -> new UserNotFoundException("id: " + id))
Optional 不是万能解药，它不能消除业务中的空逻辑，但能让空值意图可见、处理路径强制、错误提前暴露。关键在设计阶段就决定“这里该不该有值”，再用 Optional 把这个决定编码进类型里。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
