java stream api 不支持直接抛出受检异常，需通过 try-catch 转换、封装安全方法、工具函数包装或 optional/either 等方式处理，兼顾简洁性与错误语义。
Java Stream API 本身不支持直接抛出受检异常（checked exception），因为函数式接口如 Function、Consumer 等的抽象方法签名不声明 throws Exception。这意味着你在 map、filter、forEach 等操作中调用可能抛出受检异常的方法时，必须主动处理——否则编译失败。核心矛盾在于：函数式风格追求简洁表达，而异常处理需要显式控制流。解决的关键不是回避异常，而是选择适合场景的封装与隔离方式。
在 Lambda 内部用 try-catch 捕获并转换
这是最直接、无需额外依赖的方式，适用于简单、偶发、可本地消化的异常（比如解析字符串失败、空值访问）。关键不是“吞掉异常”，而是明确决策：是跳过、替换为默认值，还是转为运行时异常中断流程。
- 遇到
NumberFormatException时返回null，后续用filter(Objects::nonNull)清洗 - 遇到
NullPointerException时返回兜底字符串（如"UNKNOWN"），保持流不中断 - 若异常表示严重逻辑错误（如配置缺失），则包装成
RuntimeException抛出，让上游决定是否捕获
把异常处理逻辑提取到独立方法
当转换逻辑稍复杂，或同一异常处理模式在多处复用时，硬编码 try-catch 在 lambda 里会降低可读性。把转换逻辑和异常处理一起封装成普通方法，既符合单一职责，又便于单元测试和复用。
- 定义一个
safeParseInt(String s)方法，内部 try-catch，返回Optional<integer></integer>或-1等哨兵值 - 在 stream 中直接引用：
stream.map(this::safeParseInt)，语义清晰，lambda 体干净 - 若需区分异常类型做不同响应（如网络超时重试、格式错误丢弃），该方法也更容易扩展
用工具函数包装受检异常调用
面对大量涉及 I/O 或外部服务的受检异常（如 IOException、SQLException），重复写 try-catch + RuntimeException 包装很冗余。定义一个通用的 wrap 工具方法，把 CheckedFunction 转为标准 Function，能显著减少样板代码。
- 声明自定义函数式接口：
@FunctionalInterface interface CheckedFunction<t> { R apply(T t) throws Exception; }</t> - 提供静态包装方法：
public static <t> Function<t> wrap(CheckedFunction<t> f)</t></t></t> - 使用时：
stream.map(wrap(s -> Files.readString(Paths.get(s))))，异常自动转为RuntimeException
用 Optional 或自定义结果类型承载异常信息
当异常不是错误，而是业务流程的一部分（例如“用户不存在”“库存不足”），强行中断或静默忽略都不合适。此时应让每个元素的处理结果明确携带成功/失败状态，避免副作用扩散。
- 返回
Optional<result></result>：成功则Optional.of(result)，失败则Optional.empty() - 使用类似
Either<error success></error>的类型（可用 Vavr 库或手写简单实现），让失败原因可追溯、可聚合 - 后续可通过
flatMap展开成功值，或用collect(Collectors.groupingBy(...))分离成功与失败项
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
