Optional的核心是显式化“可能无值”的语义并流程化处理，适用于查找类单对象返回且存在合理空态的场景，应统一用ofNullable封装，结合map链式处理嵌套逻辑，并用orElse/orElseGet/orElseThrow明确空值策略。
用 Optional 封装复杂业务返回结果，核心不是“套一层”，而是**把“可能没有值”这个语义显式化、流程化、不可绕过**。它适用于你本就要返回单个对象、且该对象天然存在“查不到/不适用/暂未生成”等合理空态的场景，比如查询用户、获取配置、解析外部数据等。
明确哪些场景适合封装为 Optional
不是所有返回值都该用 Optional。重点看三点：
- 方法语义本身是“查找”或“尝试获取”——例如
findById、findConfigByKey、parseJsonAsOrder，失败是正常路径，不是异常 - 返回的是单个对象（非集合、非基本类型、非 void），且调用方需要根据“有无结果”做不同分支处理
- 该值不会被长期持有为字段，也不会作为参数传入其他方法（
Optional不应出现在方法签名入参或类属性中）
封装时优先用 ofNullable，别踩 of 的坑
业务逻辑中返回的对象往往来自数据库、缓存、HTTP 响应或 JSON 解析，这些源头本身就可能为 null。直接用 Optional.of(obj) 等于把空指针风险提前到构造阶段。
正确做法是统一用 Optional.ofNullable(obj)：
- 如果 obj 是 null，得到
Optional.empty()，后续链式调用自动短路 - 如果 obj 非 null，得到含值的
Optional，安全进入下一步 - 哪怕你“觉得它不会为 null”，也建议用
ofNullable——这是防御性编码，也是团队协作的契约
链式处理多层嵌套，替代 if-else 地狱
典型复杂场景：查用户 → 取其默认地址 → 取地址所属城市 → 取城市对应区域码。传统写法嵌套 4 层判断；用 Optional 可扁平化表达：
return Optional.ofNullable(user)
.map(User::getDefaultAddress)
.map(Address::getCity)
.map(City::getRegionCode)
.filter(Objects::nonNull) // 可选：再过滤掉值为 null 的字段（如 city.name 为 null）
.or(() -> Optional.of("CN-DEFAULT")); // Java 11+，提供兜底
关键点：
- 每个
map内部方法若返回 null，整条链自动中断，不抛 NPE - 避免在
map里做可能抛异常的操作（如 IO、计算），否则需配合try-catch或改用flatMap封装异常逻辑 - 慎用
get()—— 它必须搭配isPresent()才安全，而这种写法已退化为传统风格
对外暴露时，用 orElse / orElseGet / orElseThrow 明确空态含义
业务方法返回 Optional 后，调用方需要知道“空了怎么办”。封装时就该把兜底策略内聚进去，而不是让上游自己处理：
- 有明确默认值 → 用
orElse("default")（注意：值立即计算，适合轻量对象） - 默认值构造开销大（如 new 对象、查 DB）→ 用
orElseGet(() -> buildDefault())（延迟执行） - 空值代表业务异常（如订单不存在却要发货）→ 用
orElseThrow(() -> new BusinessException("order_not_found")) - Java 9+ 推荐
or(() -> Optional.of(...))替代orElse，语义更一致（返回仍是 Optional）
