try-catch在Stream中不改变执行模型，但位置决定异常行为：循环外捕获会熔断整个流，循环内捕获仅隔离单元素失败；中间操作不可抛检查异常，需包装为RuntimeException或改用其他方案；资源必须用try-with-resources显式管理。
try-catch 本身不改变 Stream 流的执行模型，但它在内部和外部放置时，会带来完全不同的控制逻辑、异常传播行为和业务语义。关键不是“能不能用”，而是“想让异常怎么影响数据流走向”。
循环外 try-catch：强制终止整个流处理
把 try-catch 套在整个 stream 链外面（比如包裹 forEach、collect 等终端操作），等同于给整条流水线设一个统一的“熔断开关”。只要任一环节抛出未捕获异常（包括中间操作中的 map/filter 抛 RuntimeException），整个流立即中止，后续元素不再处理，已启动的并行子任务也可能被取消。
- 适合强一致性场景：如批量扣款、事务性写库，要求“全成功或全失败”
- 注意：不会回滚已执行的副作用（比如 map 里已发 HTTP 请求、已改内存状态），需自行补偿
- 并行流下可能看到线程数骤降、日志只打印前几条——这不是并行度被改了，而是流被提前终止了
循环内 try-catch：单次迭代隔离容错
在 lambda 表达式内部使用 try-catch（例如 map 中包装远程调用），相当于为每个元素单独建一道防护墙。某次处理失败，仅该元素的结果受影响，其余元素照常流转。
- 适合高可用、容忍部分失败的场景：如批量查询用户信息，允许个别用户查不到
- 推荐返回 Optional 或自定义 Result 类型，避免用 null 引发下游空指针
- 慎在内部加 synchronized 或锁：看似容错，实则把并行流变成排队执行，CPU 利用率暴跌
Stream 中间操作里不能直接 throw 检查异常
lambda 参数类型（如 Function
立即学习“Java免费学习笔记（深入）”；
- 解决办法一：用 RuntimeException 包装检查异常，如 new RuntimeException(e)
- 解决办法二：把易错逻辑提前封装成不抛检查异常的方法（例如返回 CompletableFuture 或 Optional）
- 解决办法三：改用传统 for 循环 + try-catch，尤其当 IO 比例高时，比硬套 parallelStream 更可控
资源管理必须用 try-with-resources，别在流里 close()
Stream 本身不是 AutoCloseable（除非是 Files.lines 等特殊源），但若流源头是 FileInputStream、BufferedReader 等需要关闭的资源，必须在外层用 try-with-resources 管理，不能指望流结束自动关。
- 错误写法：
Files.lines(path).map(...).forEach(...)—— lines 返回的流未关闭，文件句柄泄露 - 正确写法：
try (Stream<string> s = Files.lines(path)) { s.map(...).forEach(...); }</string> - 多个资源可嵌套或用分号分隔：
try (var in = new FileInputStream(...); var out = new FileOutputStream(...)) { ... }
