受检异常必须显式转为非受检异常或封装处理，否则会导致流静默中断；正确做法是用fromCallable包装、手动转换重抛或预处理封装，且错误处理需靠近风险源并避免吞异常。
反应式编程中，受检异常（如 IOException、SQLException）无法直接抛出到链式操作符中，因为大多数 Reactor 操作符（如 map、flatMap）只接受不抛异常的函数式接口（如 Function<t r></t>）。若在这些函数体内直接调用声明了受检异常的方法，又未做适配，编译会失败；而开发者常误用强制捕获+忽略、或用 try-catch 吞掉异常却不转发错误信号，结果就是流静默中断——既没输出、也没日志、更没 fallback，表现为“过早终止”。
确认是否真由受检异常引发中断
先排除其他常见原因（如空指针、背压溢出），聚焦受检异常场景：
- 检查代码中是否出现类似
new FileInputStream(...)、Class.forName(...)、stmt.executeQuery(...)等明确抛出受检异常的调用 - 查看订阅下游的
onError回调是否被调用——若完全没触发，大概率是异常在 operator 内部被吞了，而非走标准 onError 通路 - 在疑似位置加
doOnNext和doOnError，观察数据是否在某步后戛然而止且无错误日志
修复受检异常的三种合规写法
不能让受检异常“逃逸”进函数式接口，必须显式转为非受检异常或封装处理：
-
用
fromCallable包装：将可能抛受检异常的逻辑放入Callable，Reactor 会自动将其包装为RuntimeException并发出 onError 信号
✅ 正确示例：
Flux.fromCallable(() -> {<br> return Files.readString(Paths.get("config.txt"));<br>}).onErrorMap(e -> new RuntimeException("读配置失败", e)) -
手动转换并重抛：在
map等操作中用 try-catch 捕获受检异常，再以RuntimeException包装后throw
⚠️ 注意：不能只catch而不throw，否则流就停在那一步，后续数据全丢 -
用工具方法预处理：封装通用转换器，如
Functions.sneakyThrow()（需谨慎评估可维护性），避免每处重复 try-catch
验证流是否真正恢复或降级
即使加了 onErrorReturn 或 onErrorResume，也要确认它们生效位置是否覆盖受检异常发生点：
- 操作符作用域是链式的——
onErrorResume只捕获它之前操作产生的错误。若受检异常发生在flatMap内部但onErrorResume写在flatMap外层，可能无效 - 推荐把错误处理尽量靠近风险源，例如：
flatMap(data -> Flux.fromCallable(() -> riskyDbCall(data))<br> .onErrorResume(e -> Mono.just(defaultValue)))
- 启用 Reactor 的调试模式（
Hooks.onOperatorDebug()）可打印详细栈信息，定位异常实际发生位置
避免典型陷阱
这些做法看似能“跑通”，实则掩盖问题、破坏响应式契约：
- 在
map中 catch 受检异常后返回null—— 导致后续NullPointerException，二次崩溃 - 用
subscribe(..., err -> {})空实现 onError —— 错误被吞，监控告警失效 - 误以为
retry能重试受检异常调用 —— 若异常源于资源不可用（如文件被删），重试只会重复失败，还可能加重负载
