forEach不支持受检异常且无容错机制，应避免在其中写核心业务逻辑；需容错时优先用for循环或map+Optional封装结果统一处理。
forEach本身不支持直接抛出受检异常，也不提供内置的“跳过失败项继续执行”机制，所以流处理中一旦出错就中断——这不是设计缺陷，而是语义使然。真正要解决中断难题，关键不是强行让forEach“扛住异常”，而是选对工具、分清场景、做好隔离。
明确 forEach 的定位：它不是错误容忍型操作
forEach 是终端操作，强调“副作用执行”，不返回新流，也不聚合结果。它的 Consumer 接口只接受 RuntimeException；若内部抛出 IOException、SQLException 等受检异常，编译直接报错。强行用 try-catch 吞掉异常再静默跳过，看似“不中断”，实则掩盖问题、丢失上下文、难以追踪失败项。
- 别在 stream.forEach 中写业务核心逻辑，尤其涉及 I/O、DB、网络调用
- 需要容错遍历？优先用 for 循环或迭代器显式控制
- 需要收集成功/失败结果？改用 collect(Collectors.partitioningBy(...)) 或自定义 Collector
替代方案：用 map + Optional 或自定义容器封装结果
把每个元素的处理包装成可失败、可携带状态的操作单元，再统一收口处理：
- 用 map(e -> tryProcess(e)) 把每个元素转为 Optional
或 ResultWrapper（含 status/code/data 字段） - 后续用 filter(Optional::isPresent) 提取成功项，或用 flatMap(Optional::stream) 展平
- 失败项可单独 collect 到 List，用于日志、重试或告警
示例（Java）：
List<ResultWrapper> outcomes = list.stream()
.map(item -> {
try {
return new ResultWrapper("success", process(item));
} catch (IOException e) {
return new ResultWrapper("fail", e.getMessage());
}
})
.collect(Collectors.toList());
真正需要“流式容错”的场景：用 for + try-catch 更清晰
当处理一批订单、文件、API 请求，且要求“单个失败不影响其余”时，增强 for 循环反而更直观、可控、易调试：
- 每轮独立 try-catch，异常可记录、可补偿、可标记跳过
- 可随时 break/continue，支持条件退出或限流控制
- 避免 Stream 的延迟求值陷阱（如中途异常导致上游未触发）
示例（C#）：
foreach (var order in orders) {
try {
await ProcessOrderAsync(order);
successCount++;
}
catch (TimeoutException) {
logger.Warn($"Order {order.Id} timeout, skipped");
failedOrders.Add(order.Id);
}
catch (Exception ex) {
logger.Error(ex, $"Failed to process order {order.Id}");
}
}
特殊需求：必须用 Stream 且需中断后恢复？考虑分片重试
如果数据量大、失败率低、且业务允许“分段重试”，可将原始集合切块，每块走独立 stream 处理：
- 用 Guava 的 Lists.partition 或 Java 17+ 的 List.chunked() 分批
- 每批用 stream.collect() 处理，捕获整批异常后记录偏移，再重试该批次
- 适合离线批量任务，不适合实时流
