Spring WebFlux使用suspend函数时在何处创建协程作用域？

你的推测方向完全正确，协程作用域确实是在请求匹配到对应处理逻辑后、调用suspend处理方法前创建的，大部分人找不到源码的核心原因是：这部分Kotlin专属适配逻辑没有放在spring-webflux的核心响应式处理链里，而是拆分到了Spring核心模块的Kotlin扩展包中，核心实现分两个场景：

注解式控制器（@Controller/@RestController）场景 #

负责suspend控制器方法适配的核心组件是KotlinCoroutinesHandlerAdapter，它是RequestMappingHandlerAdapter的Kotlin专属扩展：

• 当请求路由匹配完成后，适配器会先检测目标处理方法是否为suspend修饰的函数
• 如果是suspend方法，不会走普通的Mono/Flux返回值处理逻辑，而是调用CoroutinesUtils.invokeSuspendingFunction()工具方法启动协程：
  • 协程默认以Dispatchers.Unconfined启动，后续执行响应式操作（WebClient调用、CoroutineCrudRepository操作等）时会自动切换到对应响应式调度器
  • 协程的Job直接和当前请求的ServerWebExchange生命周期绑定，客户端断开连接、请求异常中断、响应完成时会自动触发Job取消，终止所有子协程，避免泄漏
  • 协程执行的最终结果会被包装为Mono<Any>接入WebFlux原生的响应式处理链，和普通响应式返回值走完全一致的后续消息转换、响应写回逻辑

函数式路由（Router DSL）场景 #

如果使用Kotlin DSL写函数式路由，协程作用域的创建逻辑封装在CoRouterFunctionDsl内部：

• 当你在DSL中传入suspend修饰的处理lambda时，框架会自动将其包装为标准的HandlerFunction接口实现
• lambda实际执行时，同样调用CoroutinesUtils启动绑定当前ServerRequest生命周期的协程，逻辑和注解控制器的协程启动逻辑完全复用

补充说明 #

所有Spring生态组件的协程桥接逻辑，最终都复用CoroutinesUtils的协程启动能力，覆盖的场景包括但不限于：

• Spring Data 的CoroutineCrudRepository数据操作
• Spring Security 的suspend鉴权方法
• Spring Cloud 的suspend RPC调用
• Spring Messaging 的suspend消息处理方法

这套统一桥接逻辑的协程上下文已经内置了响应式上下文传播、异常透传、生命周期绑定的能力，业务代码完全不需要手动创建协程作用域，也不需要额外处理协程和响应式流的桥接。

注意：如果你在suspend处理方法中手动使用GlobalScope启动协程，这部分协程不会被请求生命周期绑定，会存在协程泄漏风险。业务侧如果需要启动子协程，直接使用当前suspend函数自带的协程上下文即可，父协程取消时子协程会被同步回收。

内容的提问来源于stack exchange，提问作者Saffie