java调用kotlin协程需用runblocking+try-catch或completabledeferred桥接；webflux异常须通过errorwebexceptionhandler或onerror操作符处理，不走@controlleradvice；混用时需逐层转化异常，统一归一化处理。
Java 项目中集成 Kotlin 协程或 Spring WebFlux 时，全局异常处理不能套用传统 Spring MVC 的 @ControllerAdvice + @ExceptionHandler 模式——因为两者运行在完全不同的执行模型上：协程基于挂起函数和结构化并发，WebFlux 基于 Reactor 的响应式流。异常不会自然“冒泡”到 Java 的调用栈顶层，必须按各自机制对齐处理路径。
协程异常：Java 调用方需主动桥接，无法依赖全局处理器
Java 代码调用 Kotlin 协程（如 suspend 函数）时，不能直接使用 CoroutineExceptionHandler，因为该处理器只对 Kotlin 协程作用域内启动的 launch 生效，而 Java 无协程上下文概念。
- 必须用
runBlocking包裹调用，并在内部手动 try-catch：
// Java 侧调用示例
try {
String result = runBlocking(new Function1
@Override
public String invoke(CoroutineScope scope) {
return KotlinApi.fetchData(scope); // suspend 函数
}
});
} catch (CancellationException e) {
// 协程取消，非业务错误，通常忽略
} catch (RuntimeException e) {
// 真正的业务异常，如 IOException、IllegalArgumentException
log.error("Kotlin suspend call failed", e);
}
- 避免在高并发场景下滥用
runBlocking，它会阻塞线程；更适合 CLI、测试或初始化逻辑。 - 若需非阻塞交互，应通过
CompletableDeferred将 Kotlin 协程转为 JavaCompletableFuture，再用handle()或exceptionally()处理异常。
WebFlux 异常：走 Reactor 的 onError 链，与 ControllerAdvice 无关
Spring WebFlux 中，控制器返回 Mono 或 Flux，异常发生在异步流中，不会触发 @ControllerAdvice 的 @ExceptionHandler 方法——除非你显式调用 onErrorResume、doOnError 或全局 ErrorWebExceptionHandler。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 推荐方式是实现
ErrorWebExceptionHandler接口，注册为@Bean，统一拦截所有未处理的流异常：
// Kotlin 示例（Java 类同理）
@Bean
fun errorWebExceptionHandler(): ErrorWebExceptionHandler {
return object : AbstractErrorWebExceptionHandler(
errorAttributes, resourceProperties, webProperties, applicationContext
) {
override fun prepareRouting(
exchange: ServerWebExchange,
throwable: Throwable
): Mono
return when (throwable) {
is ValidationException -> ServerResponse.badRequest().syncBody("参数校验失败")
is BusinessException -> ServerResponse.status(409).syncBody(throwable.message)
else -> ServerResponse.status(500).syncBody("服务内部错误")
}
}
}
}
- 不要在 controller 方法里写 try-catch——异常会被 Reactor 捕获并转为 onError 信号；应在流链路中用
onErrorMap、onErrorResume转换或兜底。 - WebFlux 不支持
@ResponseStatus注解自动设状态码，必须显式构造ServerResponse。
混合场景：协程 + WebFlux 共存时的异常归一化
当 Kotlin 协程被用于 WebFlux 的 service 层（例如用 suspend fun 实现数据访问），异常会先经过协程传播，再进入 Reactor 流。此时需注意两层异常的衔接：
- Kotlin 协程抛出的异常（如
IOException）会被awaitSingle()或asFlow().single()自动转为 Reactor 的onError； - 但
CancellationException默认被 Reactor 忽略（视为正常取消），不会触发错误处理器；若需记录，须在协程侧用NonCancellable或withContext(NonCancellable)显式捕获； - 建议在协程 service 层统一包装业务异常为自定义
WebException，再由 WebFlux 的ErrorWebExceptionHandler统一映射 HTTP 状态码和响应体，避免异常类型泄漏到 controller。
关键差异总结
协程异常靠 runBlocking + try-catch 或 CompletableFuture 桥接；WebFlux 异常靠 ErrorWebExceptionHandler 或流操作符拦截；二者都不走 Spring MVC 的异常解析器链。混用时，异常要“一次捕获、逐层转化”，而不是期待某一个全局切面自动覆盖全部。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
