Optional不能替代null检查，只是封装判空逻辑；它不阻止传入null，仅强制显式处理空值；正确用法是ofNullable()构造、避免get()前不校验、链式map/flatMap扁平化操作，且仅适用于方法返回值。
Optional 不能替代 null 检查，只是封装了判空逻辑
很多人误以为用了 Optional 就能“自动”避免空指针异常，其实不然。它本身不阻止你传入 null，也不拦截方法调用；它只是一个**容器类**，强制你在解包前显式处理“值可能不存在”的情况。
常见错误是这样写：
Optionalopt = Optional.of(null); // 直接抛出 NullPointerException
正确做法是：
-
Optional.of(value)：仅当value确保非null时使用 -
Optional.ofNullable(value)：唯一安全的构造方式，value为null时返回Optional.empty() - 永远别对
Optional对象本身调用.get()前不检查.isPresent()或不用.orElse()类方法
链式调用中 map/flatMap 是避免嵌套判空的关键
当你有一串可能为空的对象引用（比如 user.getAddress().getCity().getName()），传统写法要层层判空；用 Optional 配合 map 可以扁平化处理。
立即学习“Java免费学习笔记（深入）”；
区别在于：
-
map：适用于返回普通对象的函数，结果自动包装成Optional；若上游是empty，整个链短路返回empty -
flatMap：适用于返回Optional的函数，避免嵌套Optional>
示例：
OptionaluserOpt = Optional.ofNullable(user); String cityName = userOpt .map(User::getAddress) .map(Address::getCity) .map(City::getName) .orElse("未知城市");
不要把 Optional 用作字段或方法返回值以外的场景
Optional 被设计为**短期存在、即用即弃**的返回类型，JDK 明确不建议：
- 作为实体类的字段（如
private Optional）——序列化、反射、ORM 映射都会出问题name; - 作为
@RequestParam或@RequestBody的参数类型（Spring 不支持） - 在集合中存储（如
List）——语义混乱，且增加 GC 压力>
它只应在**方法返回值**中表明“这个结果可能没有”，让调用方立刻意识到需要处理缺失情况。
性能与可读性权衡：简单判空不如直接 if，复杂流程才值得用 Optional
对单层判空，比如 if (str != null) { ... }，硬套 Optional.ofNullable(str).map(...).orElse(...) 反而更啰嗦、更慢（对象创建开销）。
真正适合 Optional 的场景是：
- 多个可能为空的中间步骤需要组合（如上面的 user→address→city→name）
- API 设计上想明确表达“无值”是一种合法状态，而非异常
- 配合 Stream 的
filter、findFirst等操作做声明式处理
记住：Optional 不是银弹。它解决的是“如何优雅表达可选性”，不是“怎么消灭 null”。null 本身没坏，坏的是隐式假设它不为 null。
