optional 的核心是显式表达“值可能缺失”的契约，避免 npe；它通过容器化封装强制安全操作，而非替代 null 的万能工具，不应用于字段、参数或基本类型返回值，且 ispresent()+get() 违背函数式理念，应优先使用 orelse、ifpresent、map 等声明式方法。
Java 中 Optional 的面试题，核心不是考你背 API，而是看你是否真懂它设计的初衷、适用边界和常见误用。写实战类面试题，要围绕“真实开发痛点”展开，避免纯语法默写。
紧扣空指针场景设计题目
直接抛出一个典型 NPE 风险代码，要求用 Optional 改写并说明改进点。例如：
// 原始代码（可能 NPE） String name = user.getAddress().getCity().toUpperCase();
追问：这样链式调用是否安全？Optional.ofNullable(user) 能否直接解决？为什么推荐用 map() + flatMap() 分层包裹？
考察对 Optional 本质的理解
避免把 Optional 当作“高级 null”，重点问设计意图：
-
Optional是容器，不是替代 null 的万能工具 —— 它不适用于字段、方法返回值为基本类型、或作为 Map 的 key/value -
isPresent()+get()写法本质上是“换汤不换药”，违背函数式风格，应优先用ifPresent()、orElse()、map() - 为什么
Optional.empty()比null更具表达力？它如何让 API 合约更清晰？
结合 Spring 或业务逻辑出题
给一段 Spring Data JPA 的代码：
Optional<user> optUser = userRepository.findById(123L); User user = optUser.get(); // ❌ 危险 </user>
请写出三种安全取值方式，并说明各自适用场景：
- 有默认用户对象 →
optUser.orElse(defaultUser) - 需抛自定义异常 →
optUser.orElseThrow(() -> new UserNotFoundException()) - 仅需处理存在时的逻辑 →
optUser.ifPresent(u -> sendWelcomeEmail(u))
设置陷阱题检验深度
给出错误用法，让指出问题：
public Optional<string> findName() {
return Optional.of(getName()); // ❌ getName() 可能返回 null
}
</string>
正确写法是：return Optional.ofNullable(getName())。
再追问：如果 getName() 是私有方法且内部已确保非 null，是否还该用 Optional 包装？为什么？
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
