Optional 应作为支持链式操作的计算容器，而非可空包装；需用 map、flatMap、orElse 等声明式方法扁平化空值处理，避免 isPresent() + get() 嵌套。
用 Optional 避免嵌套判空，核心是别把 Optional 当成“可空包装”，而要把它当作**支持链式操作的计算容器**。关键不是层层 isPresent() + get()，而是用 map、flatMap、orElse 等方法把空值逻辑声明化、扁平化。
用 flatMap 拆解多层 Optional
当你要从一个 Optional<user></user> 取 Optional<address></address>，再取 Optional<string></string> 的城市名，直接嵌套 get() 会崩溃或写一堆 if。正确做法是让每一步返回 Optional，再用 flatMap 连接：
-
userOpt.flatMap(u -> u.getAddressOpt())把User → Optional<Address>转成Optional<Address> - 再链式
.flatMap(a -> a.getCityOpt())得到Optional<String> - 最后用
orElse("未知")统一兜底
把 null 返回值转成 Optional，统一入口
很多老代码方法返回 null（比如 getUserById(id)），先用 Optional.ofNullable() 包一层，后续就全是函数式链路：
Optional.ofNullable(getUserById(123))- 接着
.map(User::getProfile).map(Profile::getAvatarUrl).orElse("/default.png") - 全程无
== null，也无需提前if (u != null)
用 orElseGet 延迟计算默认值
避免在非空时也执行开销大的默认逻辑。比如查不到用户时要调用远程服务兜底：
立即学习“Java免费学习笔记（深入）”；
- 错：
userOpt.orElse(fetchDefaultUser())—— 无论是否空都会执行fetchDefaultUser() - 对：
userOpt.orElseGet(() -> fetchDefaultUser())—— 只在空时才调用
慎用 isPresent() + get()，尤其别嵌套
写成 if (opt1.isPresent()) { if (opt2.isPresent()) { ... } } 就退回了 if-else 泥潭，失去了 Optional 的意义。只要出现 isPresent()，就该问问：能不能用 map/flatMap/filter 替代？能不能用 ifPresent 做副作用（如打日志）而不中断链路？
不复杂但容易忽略：Optional 的价值不在“避免 NPE”，而在把空值处理变成可组合、可读、可测试的声明式流程。
