Try 不能直接替代 try-catch，因为它是值类型，封装异常而非抛出，若未妥善解包（如误用 get()）会掩盖原始异常；适合有明确兜底策略的场景，不适用于需立即中断告警的关键流程。
为什么 Try 不能直接替代 try-catch
因为 Try 是值类型（Success 或 Failure），它不抛异常，而是把异常封装成数据。你写 Try.of(() -> riskyMethod())，哪怕 riskyMethod() 抛了 NullPointerException，也不会中断执行流——但如果你忘了用 .getOrElse()、.get() 或 .onFailure() 拆包，就可能在后续调用时突然触发 get() 的隐式异常，反而更难定位。
常见错误现象：Try.get() 在 Failure 上被调用 → 抛出 NoSuchElementException，掩盖原始异常；或链式调用中某步返回 Try.failure(new RuntimeException())，但下游没检查就直接 .map()，结果静默跳过逻辑。
-
Try适合「已知可能失败、且失败后有明确兜底策略」的场景，比如读配置、解析 JSON、查缓存 - 不适合「必须中断流程并告警」的场景，比如支付扣款失败要立刻回滚+通知运维
-
Try.of()捕获的是Throwable，包括Error（如OutOfMemoryError），生产环境建议用Try.of(() -> {...}).filter(t -> !(t instanceof Error))排除致命错误
map 和 flatMap 的异常传播差异
map 里抛异常 → 自动转为 Failure；flatMap 返回的 Try 如果是 Failure，会直接穿透，不会二次包装。这是链式容错的关键。
使用场景：连续调用三个可能失败的操作（读 DB → 调第三方 API → 写日志），用 flatMap 可自然短路；若中间某步用 map 处理数据但意外抛异常，Try 仍能捕获并继续传递。
立即学习“Java免费学习笔记（深入）”；
示例：
Try<String> result = Try.of(() -> db.loadUser(123))
.flatMap(user -> Try.of(() -> api.sendWelcomeEmail(user.email)))
.map(logResponse -> "sent")
.recover(t -> "fallback");
- 如果
db.loadUser()失败 → 整个链是Failure，跳过后续flatMap和map - 如果
api.sendWelcomeEmail()抛IOException→flatMap返回Failure，同样短路 - 但
.map(logResponse -> "sent")里若手动 throw new RuntimeException() → 会被Try捕获为新Failure，不是崩溃
Vavr Try 和 Java 8 Optional 的误用边界
Optional 表达「值可能不存在」，Try 表达「计算可能失败」——语义不同，强行混用会模糊错误意图。
常见错误现象：用 Optional.ofNullable(someRiskyCall()) 代替 Try.of(() -> someRiskyCall())，结果 someRiskyCall() 抛异常直接炸掉，Optional 根本没机会生效。
-
Optional.empty()不等于Try.failure(new Exception())：前者是“无值”，后者是“有失败记录” - 不要对
Try做.toOptional().orElse(null)，这丢掉了异常堆栈；要用.getOrElse(() -> null)或.onFailure(System.err::println) - 兼容性注意：Vavr 0.10+ 默认启用不可变集合，
Try也是不可变的，反复.map()不会修改原对象，但旧版本有可变变体，容易踩坑
如何让 Try 真正参与业务错误分类
默认 Try.failure(e) 只存异常实例，但业务常需区分「参数错」「系统错」「第三方超时」。得靠自定义异常类型 + recoverWith 或模式匹配。
性能影响：每次 recoverWith 都会新建 Try 实例，高频调用路径慎用；更轻量的做法是用 fold 统一分发逻辑。
示例（按异常类型分流）：
result.fold(
error -> {
if (error instanceof TimeoutException) return handleTimeout();
if (error instanceof ValidationException) return handleValidation();
return handleUnexpected(error);
},
success -> onSuccess(success)
);
-
fold是最安全的消费方式，强制处理成功/失败两种分支 - 避免在
recover里写复杂逻辑，它只适合简单 fallback；复杂恢复策略放fold或单独方法 - 日志埋点别只打
error.toString()，用error.getCause()和error.getStackTrace()才能保留根因
真正难的不是写 Try.of()，是设计好 failure 的语义分层——比如要不要把网络超时和 JSON 解析失败归为同一类可重试错误，这个决策比语法细节重要得多。
