Optional 这题"第一层"是：Optional 是容器，解决"方法可能没有返回值"的表达问题。第二层是它的适用边界——哪些地方能用、哪些地方用了反而是灾难。第三层是它与序列化框架、与 Kotlin 空安全、与性能（Optional 是对象，链式调用会产生多个实例）的配合。多数人只答到第一层，于是写出"把 Optional 当字段"这类线上事故。
先把结论放在前面：Optional<T> 是一个容器，值可以是 T 也可以是"空"。它的价值是把空这件事表达在类型里，让编译期和 IDE 都能提示你处理缺失。 核心方法分四组：of/ofNullable 创建，isPresent/isEmpty 判断，map/flatMap/filter 变换，orElse/orElseGet/orElseThrow 取值。核心纪律：只作为方法返回值使用，不做字段、不做参数传递。
机制拆解
Optional 的运行机制很轻：内部持有一个 value 字段，空实例就是 value == null 的那一个。map 的实现是 value == null ? empty() : Optional.ofNullable(mapper.apply(value))——也就是说 map 返回的是新 Optional，空值时甚至不调用传入的函数。 flatMap 是为"函数本身就返回 Optional"设计的：它直接返回那个 Optional，避免套两层。
这带来一个常被忽略的细节：map + get 组合是好的（opt.map(Foo::bar).orElse(default)），而 map + flatMap 混用就会得到 Optional<Optional<T>>，取值时需要 flatMap 消掉外层。filter 则是把不符合谓词的值转成空。
Android 上真正值得注意的，是序列化框架与 Optional 的冲突。Gson 默认对字段用反射，Optional 内部只有一个字段，反序列化时它可能直接给 value 赋值，也可能在无参构造时给出空实例，行为取决于 Gson 版本与字段类型推断；Jackson 表现稍好但也依赖 jackson-datatype-jdk8 这类额外模块。 结论是：实体类里不要用 Optional，需要表达可空就在 JSON 里保持字段可缺省，由业务层在入口处包一层 Optional。
这些坑的正确绕法
最常见的坑是在实体字段上用 Optional，导致反序列化行为不符合预期。 表现是反序列化后字段为 Optional.empty()，取值时 .get() 抛 NoSuchElementException；或者用 Kotlin 写数据类时构造参数带 Optional，Gson 找不到合适的构造路径直接给 null。 对策是分工明确：序列化模型保持朴素（可空字段 + getter/setter 或 Kotlin 的可空类型），可空性判断在业务层用 Optional 表达。这条纪律在 Android 里几乎没有例外，因为数据来源往往是接口，而接口的字段是否可空由服务端决定，不该由客户端的类型系统去替它承诺。
其次是 Optional 当方法参数使用，调用方不得不先造一个容器。 传普通参数时传 null 就行，传 Optional 却要 Optional.ofNullable(x)，而 Optional 本身可能为空，等于要判两次。 参数可空就直接用 @Nullable 注解（AndroidX 的 androidx.annotation.Nullable），返回值可能缺失才用 Optional。这也是社区总结的那句"返回值用 Optional，参数用注解"。
还有一个更隐蔽的坑：连续 orElse 触发昂贵的重复计算。 写法是 findUser(id).map(User::getName).orElse(loadNameFromCache(id))——如果这个"或"分支里有 IO 或数据库查询，那么它在每次 Optional 为空时都会被执行；而更麻烦的是，如果链里有多个 orElse，任何一个先命中就短路，可读性也变得很差。 对策是用 orElseGet(Supplier)：它接收一个 Supplier，只在为空时调用，天然避开无效计算。orElse 传常量没问题，一旦传函数就必须换 orElseGet。
代码里见真章
看一段能直接跑的代码，把上面的机制落到具体写法上：
// Optional 只用于返回值：把"可能没有"表达在类型里
Optional<User> findUser(String id) {
User u = db.query(id);
return Optional.ofNullable(u); // 空值走 ofNullable，别用 of
}
// 变换：map 产生新 Optional，flatMap 消掉嵌套
Optional<String> city = findUser(id)
.map(User::getAddress)
.map(Address::getCity); // Optional<String>
// 参数可空用注解，不用 Optional
void render(@Nullable User user) {
... }
// orElse 传常量；orElseGet 传函数，避免重复计算
String name = findUser(id)
.map(User::getName)
.orElse("匿名"); // 常量，用 orElse
String detail = findUser(id)
.map(User::getName)
.orElseGet(() -> loadFromNetwork(id)); // 有 IO，必须用 orElseGet
// 链式判定：filter + anyMatch 组合
boolean isAdmin = findUser(id)
.map(User::getRole)
.filter("admin"::equals)
.isPresent();
// 反例：裸 get 没有语义也没有保护
// String n = findUser(id).get().getName(); // 空时抛 NoSuchElementException
这段代码值得盯三处：第一处，of 传 null 会直接抛 NullPointerException，判空场景必须用 ofNullable；第二处，orElse 与 orElseGet 的选择依据是"兜底值是否需要计算"；第三处，链式写法把"空"处理压缩在链内，调用方只需在末尾决定兜底，代码意图直接写在类型里。
这题在面试里怎么问、怎么答
"Optional 存在的意义是什么？为什么不直接返回 null？"三层答：①表达力——返回值类型本身就宣告"这里可能没有"，这是 null 做不到的；②安全性——Optional 没有公开的 null 入口，只能通过工厂方法创建，杜绝了"Optional 内部装了个 null"这种三态混乱；③可组合——map/filter 让缺失值处理能像流水线一样串起来。 也要诚实说清代价：它多了一层对象分配，Android 高频路径上要注意。
"Optional 和 Kotlin 的可空类型有什么区别？"答：Kotlin 的 T? 是语言层面的类型系统，编译器强制你在使用前做判空或用 ?./?: 表达，安全性由编译期保证；Optional 是库层面的约定，编译器不强制，裸 get() 照样能编译通过。 Kotlin 里 Foo? 与 Optional<Foo> 一般不并存，优先用语言特性，跨 Java 边界时才会见到 Optional。
"Optional 能做字段吗？"明确说不能，理由给三条：序列化框架支持参差；字段的缺失与"值为空"混在一起会让 equals/hashCode 语义模糊；Optional 本身不可序列化，跨进程还要额外处理。替代方案是字段保持可空，在访问入口处包一层 Optional 返回给业务。
"使用中遇到过什么问题？"案例一：给一个 Kotlin 数据类加了个 Optional<String> nickname 字段，用 Gson 反序列化后该字段恒为空；定位到 Gson 不支持 Optional 的构造；修复为字段改回可空 String?，在 getter 里包 Optional。 案例二：一个列表页的姓名展示偶发卡顿；定位到 orElse 里传了一个会读数据库的函数，每次都被执行；修复为改成 orElseGet。
再补一个工程上值得讲清的点：orElseThrow 的异常类型要选对。业务缺失用自定义业务异常（UserNotFoundException），参数非法用 IllegalArgumentException，状态非法用 IllegalStateException。区分清楚异常类型，调用方的 catch 分支才不会互相误捕。 另外 Optional 在 Android 上别用在超高频的渲染路径里——每个 map 都可能分配一个新实例，RecyclerView 绑定这种每秒执行上百次的场景，用普通判空反而更合适。这一条能体现对成本的敏感。
给正在准备面试的你
把这题画成一张"能用 / 不能用"的分界图：左边一列"推荐用法"，写三行——方法返回值用 Optional.ofNullable、链式 map/flatMap/filter 做变换、兜底用 orElse（常量）/ orElseGet（函数）/ orElseThrow（异常）；右边一列"慎用/禁用"，写三行——实体字段不用、参数不用、渲染等高频路径不用。 再在中间画一条竖线，线上标一句"可空性的表达放在类型里，序列化模型保持朴素"。面试中如果被追问"那你项目里怎么用"，就照这张图讲取舍。
再补工程案例与踩坑——应用落点是把项目里散在 Service 层的 if (user == null) return 收敛成 Optional 返回值，把 orElse 传昂贵函数的写法统一改为 orElseGet，并在实体类上清查 Optional 字段、换成可空类型加注解。
复习时别孤立刷题：Stream 常用操作——findFirst 返回的就是 Optional，filter 走 Predicate。
划两句重点：Optional 只用于返回值，ofNullable 防 NPE，orElse 传常量、orElseGet 传函数；实体字段与参数不用 Optional；链式 map 会产生新实例，高频路径慎用。
下一篇聊新时间 API：LocalDateTime 取代 Date 的理由——沿着今天这条主线继续往前走。
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。你的支持就是这个系列持续更新的动力。
「Android软件开发面试·从入门到精通」连载系列
上一篇：Stream-常用操作：map、filter-与-collect-实战
下一篇预告：新时间-API：LocalDateTime-取代-Date-的理由
有任何问题欢迎在评论区留言交流。
