Optional.ofNullable()是最安全直接的null处理方式，专为可能为空的对象设计，不抛异常、不强制预判空，通过map/filter/orElse等链式操作统一延后处理，适用于数据库查询、配置读取、嵌套属性访问等场景。
用 Optional.ofNullable() 是最安全、最直接的方式。它专为处理可能为 null 的对象设计，不会抛异常，也不会强制要求你提前做判空，而是把“是否为空”这个判断逻辑交给后续链式操作去统一处理。
为什么不用 Optional.of()？
Optional.of(null) 会立刻抛出 NullPointerException，完全违背了“安全包装”的初衷。只有当你 100% 确定值非 null 时才该用 of() —— 这种情况在实际业务中其实很少见，尤其涉及外部输入、数据库查询或 API 返回时。
正确用法：ofNullable() + 链式处理
它把判空动作封装进容器本身，后续通过 map、filter、orElse 等方法自然延后处理：
-
Optional.ofNullable(user).map(User::getName).orElse("匿名")—— user 或 name 任一为 null，都不会 NPE，最终返回默认值 -
Optional.ofNullable(str).filter(s -> s.length() > 0).map(String::toUpperCase).orElse("")—— 先判空再判空字符串，再转换，一步到位 -
Optional.ofNullable(config.getTimeout()).map(Integer::parseInt).orElse(30)—— 字符串转整数时若格式非法，建议单独封装 parse 方法（如知识库中parseAge示例），避免NumberFormatException中断链式调用
别踩的坑
几个常见但危险的做法：
立即学习“Java免费学习笔记（深入）”；
- 把
Optional当字段存进实体类 —— 它不是为持久化或序列化设计的，也不符合 JavaBean 规范 - 用
get()直接取值 —— 等于绕过 Optional 的全部意义，一旦为空就崩 - 用
isPresent()+get()写 if-else —— 回退到传统 null 检查，没发挥函数式优势 - 对集合返回
Optional<list>></list>—— 应该返回空集合Collections.emptyList()，更符合直觉和下游使用习惯
适合包装哪些对象？
核心原则：只用于方法返回值，表示“这个结果可能不存在”。典型场景包括：
- 数据库单条查询结果（如
findById()） - 配置项读取（如
getProperty("timeout")） - 嵌套对象属性访问（如
user.getAddress().getCity()这类易 NPE 链路） - 第三方 API 响应中的可选字段
