Optional不能替代try-catch，但能避免因判空引发的NullPointerException，将空值处理从异常流转为声明式数据流，从而减少冗余的防御性try-catch。
Optional 本身不能直接替代 try-catch 块，但它能帮你**避免因判空而引发的 NullPointerException**，从而减少为防空指针而写的冗余 try-catch（尤其是那种仅用来捕获 NPE 的“防御性 try”）。关键在于：用 Optional 显式表达“值可能不存在”，把空值处理逻辑从异常流转为数据流。
用 Optional 包装可能为空的返回值
很多工具方法或旧接口返回 null（如 Map.get、Dao 查询结果），这时不要自己手动判空+抛异常，而是立刻封装成 Optional：
-
❌ 错误示范（催生 try-catch）：
String name = userMap.get(userId);<br>if (name == null) { throw new IllegalArgumentException("user not found"); }
后续调用者可能又包一层 try-catch 处理这个异常。 -
✅ 正确做法（用 Optional 消除空分支）：
Optional<String> nameOpt = Optional.ofNullable(userMap.get(userId));<br>nameOpt.orElseThrow(() -> new IllegalArgumentException("user not found"));
这样空值处理是声明式的，不依赖异常机制，也不需要外层 try。
链式调用中自然规避中间 null
当涉及多层对象访问（如 user.getAddress().getCity()）时，传统写法需层层判空，容易催生嵌套 if 或 try-catch。Optional 提供 flatMap 和 map，让调用安全“短路”：
-
❌ 手动判空易出错：
if (user != null && user.getAddress() != null && user.getAddress().getCity() != null) { ... } -
✅ 用 Optional 链式表达：
Optional.ofNullable(user)<br> .map(User::getAddress)<br> .map(Address::getCity)<br> .orElse("Unknown");
任意一环为 null，后续 map 自动跳过，不会抛 NPE，也无需 try。
替代“空集合”检查，统一用 Optional>
DAO 方法常返回 null 而非空集合，导致调用方总要写 if (list != null) list.forEach(...)。改用 Optional 可统一处理：
- DAO 返回：
Optional<list>> findOrdersByUserId(Long id)</list> - 调用方直接：
ordersOpt.ifPresent(orders -> orders.forEach(this::process));
或ordersOpt.orElse(Collections.emptyList()).stream().filter(...).count();
完全绕开 null 判定和潜在的 NPE，也不需要为“list 为 null”加 try。
注意边界：Optional 不解决所有异常场景
Optional 只针对“值存在性不确定”的场景。以下情况它帮不上忙，仍需 try-catch：
- IO 异常（如文件读取、网络请求）——这是真正的外部异常，不是空值问题；
- 数值转换异常（如 Integer.parseInt("abc")）——这是格式错误，不是空；
- 业务校验失败（如余额不足）——应抛受检/运行时业务异常，与空无关。
把这些真正该用异常的地方留着，把原来为防 NPE 而写的 try-catch 全部删掉——代码会更清晰，异常语义也更准确。
