应使用 Optional 替代嵌套三目运算符，通过 ofNullable、flatMap、map、orElse 等链式调用安全处理多层空值；避免布尔包装类拆箱异常；用 filter + orElseGet 支持复杂分支逻辑；适用于方法返回值和跨层传递，而非字段或 JSON 响应。
用 Optional 替代嵌套三目，先拆掉 null 链
三目运算符嵌套三层以上（比如 user != null ? user.getProfile() != null ? user.getProfile().getName() : "anonymous" : "anonymous"）本质是把空值检查硬塞进表达式里，可读性差、易出 NPE。Optional 的链式调用天然适合解耦这种“层层判空→取值→兜底”的流程。
核心思路：把每个可能为 null 的环节包装成 Optional，再用 map、flatMap、orElse 逐级推进：
- ofNullable(user) 启动链条，安全包裹原始对象
- flatMap(u -> Optional.ofNullable(u.getProfile())) 处理中间可能返回 null 的方法调用
- map(p -> p.getName()) 对非 null 的 Profile 取名
- orElse("anonymous") 统一兜底，不重复写两次
最终一行写完：
String name = Optional.ofNullable(user).flatMap(u -> Optional.ofNullable(u.getProfile())).map(Profile::getName).orElse("anonymous");
避免三目中布尔包装类的拆箱陷阱
像 flag != null ? flag : false 这种写法看似稳妥，但若 flag 是 Boolean 包装类且为 null，JVM 在三目判断时会尝试自动拆箱，直接抛 NullPointerException。
用 Optional 更清晰安全：
立即学习“Java免费学习笔记（深入）”；
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 把布尔值也当“可能为空的数据”看待：Optional.ofNullable(flag)
- 用 orElse(false) 明确返回基本类型，不触发拆箱
- 完整写法：boolean result = Optional.ofNullable(flag).orElse(false);
这比在三目里反复加 != null 判断更语义化，也杜绝了隐式拆箱风险。
用 filter + orElseGet 实现条件分支逻辑
三目常被用来做简单分支赋值，比如：String status = isActive ? "running" : "stopped";。如果分支逻辑稍复杂（比如需要计算、查缓存、调用方法），三目就撑不住了——它只接受表达式，不能执行语句。
Optional 的 filter 和 orElseGet 组合能优雅替代：
- filter 执行布尔判断，符合条件才保留值
- orElseGet 在不满足时延迟执行 Supplier，支持任意逻辑
- 示例：String status = Optional.of(isActive).filter(b -> b).map(b -> "running").orElseGet(() -> computeStatusFromDB());
这样既保持了单表达式风格，又释放了分支内执行复杂操作的能力。
配合 Lombok 和 Spring 让 Optional 更自然
Optional 不是万能胶，强行 everywhere 用反而别扭。它最适合出现在方法返回值和跨层数据传递场景：
- Service 方法返回 Optional
，而不是 User 或 null，调用方必须显式处理空情况 - Lombok 的 @Builder 和 @Data 与 Optional 字段天然兼容，比如 private Optional
nickname; - Spring Data JPA 的查询方法默认返回 Optional，直接对接无需额外包装
注意：不要把 Optional 用作字段类型存进数据库，也不要作为 REST 接口的 JSON 响应体字段——它不是为序列化设计的。它的主战场，是代码内部的空值契约表达。
