Optional不能自动消除NullPointerException，关键在于主动设计、避免裸null、配合语义化使用；它是表达“值可能存在”的契约工具，而非null包装器。
Java中用Optional不能自动消除NullPointerException，关键在于**主动设计、避免裸null、配合语义化使用**。它不是“防错补丁”，而是表达“值可能存在”的契约工具。
别把Optional当null的包装器
错误做法：用Optional.of(null)或Optional.ofNullable(getUser()).orElse(null)——这既没提升可读性，又可能在后续调用中触发NPE。
-
正确姿势：只对本就可能为空的返回值（如查找方法、配置读取）直接返回
Optional<T> -
拒绝null入参：构造函数和setter里用
Objects.requireNonNull()校验，不让null进入对象内部 -
避免Optional字段：类属性不定义为
Optional<String> name——这违背封装，且序列化/反射易出问题
用好orElse系列，但别滥用orElseGet
orElse适合提供简单默认值（如0、""、new ArrayList<>()）；orElseGet适用于需延迟计算或有副作用的场景（如查数据库、发日志）。
-
警惕orElse里的异常：
optional.orElse(someMethodThatThrows())会在optional非空时也执行该方法，导致意外异常 -
优先用orElseGet：即使逻辑简单，也养成写
orElseGet(() -> "default")的习惯，明确延迟性 - 慎用orElseThrow：仅当空值代表业务异常（如“用户ID必存在”）时才抛自定义异常，而非替代空指针检查
链式操作代替嵌套if，但要守住边界
利用map、flatMap、filter串联逻辑，把“取值→判空→转换→再判空”压缩成一行：
立即学习“Java免费学习笔记（深入）”；
// 传统写法
User user = getUserById(id);<br>
if (user != null) {<br>
Address addr = user.getAddress();<br>
if (addr != null && "CN".equals(addr.getCountry())) {<br>
return addr.getZipCode();<br>
}<br>
}<br>
return "000000";
// Optional写法
return getUserByIdOpt(id)<br>
.map(User::getAddress)<br>
.filter(addr -> "CN".equals(addr.getCountry()))<br>
.map(Address::getZipCode)<br>
.orElse("000000");
-
map内不抛异常：确保
User::getAddress等方法不返回null（否则map结果为Optional.empty()，符合预期） - 避免在map里做复杂逻辑：如需分支处理，拆到单独方法并返回Optional，保持链清晰
- 不要为Optional而Optional：若方法语义上“必须返回有效对象”，就该返回T，而不是Optional<T>
与Stream、第三方库协同更安全
Optional天然适配Stream的findFirst、findAny；与Lombok的@Builder.Default或Spring Data JPA的查询方法（如findById）结合，能减少手动判空。
-
Spring Data示例：
Optional<Product> findByName(String name)比Product findByName(...)更明确地表达“可能找不到” -
避免混用：不把
Optional塞进List或Map作为元素——集合本身已具备“空/非空”语义，叠加Optional反而冗余 -
测试覆盖空分支：对返回Optional的方法，必须写测试验证
empty()路径的行为（如日志、默认值、异常提示）
