深度长文剖析SpringWebFlux相应式框架15个核心组件源码
Spring WebFlux 介绍Spring WebFlux 是 Spring Framework 5.0 版本引入的一个相应式 Web 框架，它与 Spring MVC 并存，提供了一种全新的编程范式，支持异步非阻塞的 Web 应用开发。WebFlux 完全基于相应式编程模型，支持 Reactive Streams 规范，可以在诸如 Netty、Undertow 以及 Servlet 3.1+ 容器上运行。
WebFlux 的核心控制器是 DispatcherHandler，它雷同于 Spring MVC 中的 DispatcherServlet，负责将哀求分发给相应的处理器。DispatcherHandler 通过查找 Spring 配置中的 HandlerMapping、HandlerAdapter 和 HandlerResultHandler 来处理哀求。
在 WebFlux 中，Flux 和 Mono 是 Reactor 库中的两个根本概念，分别用于表现包罗 0 到 N 个元素和 0 或 1 个元素的异步序列。Flux 可以用于表现一个包罗多个相应式元素的流，而 Mono 用于表现单个元素的相应式流。
Spring WebFlux 支持多种编程模式，包罗基于注解的控制器和函数式端点。开发者可以使用 @RestController 注解来创建相应式控制器，并使用 @GetMapping、@PostMapping 等注解来处理 HTTP 哀求。同时，WebFlux 也支持使用 WebClient 作为非阻塞的 HTTP 客户端来与其它服务进行通信。
WebFlux 的并发模型与传统的 Spring MVC 有明显不同。它利用了少量的线程来处理大量的并发哀求，这得益于其非阻塞的特性。当运行在 Netty 服务器上时，WebFlux 使用事件循环线程来处理哀求，制止了传统 Servlet 容器中每个哀求都需要一个线程的模型。
Spring WebFlux 的适用场景重要是 IO 密集型的应用，比方微服务网关，它可以明显提升对卑鄙服务转发的吞吐量
。然而，假如现有的 Spring MVC 应用能够满足性能需求，而且项目中使用了许多基于 Servlet 线程模型的库，那么可能没有必要迁移到 WebFlux。
源码层面，Spring WebFlux 的哀求处理流程涉及到多个组件，包罗 Netty 服务器的初始化、哀求的接收、DispatcherHandler 的哀求分发，以及最终的哀求处理和相应。在 Netty 服务器中，哀求处理涉及到 ChannelHandler，ConnectionObserver，以及 HttpHandler 等多个组件。这些组件协同工作，实现了 WebFlux 的非阻塞和相应式特性。
Spring WebFlux 都有哪些核心组件
Spring WebFlux 包罗多个核心组件，它们共同构成了完备的相应式 Web 应用框架。下面是一些重要的核心组件：
[*]DispatcherHandler：这是 WebFlux 的中央调理器，雷同于 Spring MVC 中的 DispatcherServlet。它负责发现和调理 HTTP 哀求处理器（handlers），并处理哀求映射、调用和效果处理。
[*]HandlerMapping：这个接口用于将哀求映射到对应的处理器（handler）。它在应用程序上下文中被检测到，并用于确定哀求应该由哪个处理器处理。
[*]HandlerAdapter：这个接口帮助 DispatcherHandler 调用任何类型的处理器，而不需要关心详细的调用方式。它为不同的处理器提供了调用策略。
[*]HandlerResultHandler：这个接口处理处理器调用后的效果，并生成最终的相应。它负责将处理器的效果转换为客户端可以接收的格式。
[*]WebFilter：WebFilter 接口界说了一组过滤器，这些过滤器可以对哀求和相应进行预处理和后处理。
[*]ServerWebExchange：这个类封装了 HTTP 哀求和相应的所有信息，比方哀求头、哀求体、URI、参数等。
[*]ServerHttpRequest 和 ServerHttpResponse：这两个类分别代表服务器接收的 HTTP 哀求和发送的 HTTP 相应。
[*]WebSession：用于管理特定客户端的会话信息。
[*]Reactive Streams：WebFlux 基于 Reactive Streams 规范，使用非阻塞背压机制来处理数据流。
[*]Reactor 库：作为 Spring 5 的反应式编程基础，Reactor 提供了非阻塞的编程模型和工具，包罗 Flux 和 Mono 等反应式类型。
[*]WebClient：这是 Spring 5 中引入的非阻塞、支持相应式流的 HTTP 客户端，用于与其它服务进行通信。
[*]Spring Data Reactive：提供对相应式数据访问的支持，比方 Reactive Repositories。
[*]Spring Security Reactive：提供对相应式安全访问控制的支持。
[*]HttpHandler：界说了最低级别的反应式 HTTP 哀求处理条约，作为不同运行时之间的共同基础。
[*]ContextPathCompositeHandler：答应在不同的上下文路径上注册多个应用程序。
这些组件共同工作，为开发人员提供了一个强大且灵活的相应式 Web 应用开发平台。通过这些组件，开发者可以构建出能够高效处理大量并发哀求的应用程序。下面针对这些组件，V 哥将一一详细介绍核心源码的实现过程，帮助兄弟们彻底理解。
1. DispatcherHandler
DispatcherHandler 是 Spring WebFlux 的核心组件，它的作用雷同于 Spring MVC 中的 DispatcherServlet。它负责将传入的 HTTP 哀求分发给相应的处理器（handler），并处理哀求的映射、调用和效果处理。以下是对 DispatcherHandler 组件源码实现逻辑和步骤的详细分析：
初始化过程
[*]ApplicationContextAware 实现：DispatcherHandler 实现了 ApplicationContextAware 接口，这意味着它可以访问到 Spring 应用上下文中的 Bean。
[*]HandlerMapping、HandlerAdapter 和 HandlerResultHandler 的初始化：DispatcherHandler 在初始化时会查找 Spring 应用上下文中所有的 HandlerMapping、HandlerAdapter 和 HandlerResultHandler 并初始化它们。
protected void initStrategies(ApplicationContext context) {
// ... 省略部分代码 ...
this.handlerMappings = ...;
this.handlerAdapters = ...;
this.resultHandlers = ...;
}哀求处理过程
[*]获取 HandlerMappings：DispatcherHandler 会通过 handlerMappings 来查找能够处理当前哀求的 HandlerMapping。
[*]映射哀求到 Handler：使用找到的 HandlerMapping 将哀求映射到详细的处理器（可能是一个 @Controller 方法大概一个 RouterFunction）。
[*]调用 Handler：一旦找到处理器，DispatcherHandler 会使用适当的 HandlerAdapter 来调用处理器。
[*]处理效果：处理器的执行效果会被 HandlerResultHandler 处理，生成相应。
核心方法：handle
DispatcherHandler 的核心方法是 handle，它界说了哀求处理的流程：
public Mono<Void> handle(ServerWebExchange exchange) {
// 检查是否初始化了 handlerMappings
if (this.handlerMappings == null) {
return createNotFoundError();
}
// 使用 handlerMappings 来查找 handler
return Flux.fromIterable(this.handlerMappings)
.concatMap(mapping -> mapping.getHandler(exchange))
.next() // 获取第一个 handler
.switchIfEmpty(createNotFoundError()) // 如果没有找到 handler，返回错误
.flatMap(handler -> invokeHandler(exchange, handler)) // 调用 handler
.flatMap(result -> handleResult(exchange, result)); // 处理结果
}错误处理
[*]createNotFoundError：假如没有找到合适的处理器，DispatcherHandler 会创建一个表现 "Not Found" 的相应。
其他组件的协同工作
[*]HandlerMapping：负责将哀求 URL 映射到详细的处理器。
[*]HandlerAdapter：负责调用详细的处理器，Spring WebFlux 支持多种类型的处理器，HandlerAdapter 使得 DispatcherHandler 无需关心详细的调用细节。
[*]HandlerResultHandler：负责处理处理器的返回值，并将其转换为 HTTP 相应。
DispatcherHandler 的计划使得它非常灵活，可以很容易地扩展新的 HandlerMapping、HandlerAdapter 或 HandlerResultHandler 来支持不同的处理器类型和返回类型。
以上就是 DispatcherHandler 组件的源码实现逻辑和步骤的分析。通过这种方式，Spring WebFlux 能够以非阻塞的方式处理 Web 哀求，提高应用的性能和可伸缩性。
2. HandlerMapping
HandlerMapping 是 Spring WebFlux 中的一个接口，它界说了将哀求映射到处理器（handler）的逻辑。HandlerMapping 的实现类负责根据哀求的类型、URL 模式等信息来确定哪个详细的处理器应该处理当前的哀求。以下是对 HandlerMapping 组件的源码实现逻辑和步骤的详细分析：
HandlerMapping 接口界说
HandlerMapping 接口界说了以下关键方法：
public interface HandlerMapping {
Mono<Object> getHandler(ServerWebExchange exchange);
void afterPropertiesSet();
}
[*]getHandler：根据给定的 ServerWebExchange 对象，返回一个 Mono 对象，该 Mono 完成时包罗哀求的处理器。
[*]afterPropertiesSet：在所有属性都设置之后调用，答应 HandlerMapping 实现进行初始化。
重要实现类
Spring WebFlux 提供了几个 HandlerMapping 的实现类，重要包罗：
[*]RequestMappingHandlerMapping：处理基于注解的映射，比方 @RequestMapping、@GetMapping 等。
[*]RouterFunctionMapping：处理基于 RouterFunction 的函数式路由。
[*]SimpleUrlHandlerMapping：处理简朴的 URL 到对象的映射。
RequestMappingHandlerMapping 源码分析
RequestMappingHandlerMapping 是最常用的 HandlerMapping 实现之一，下面是它的一些关键实现逻辑：
[*]注册和剖析：在初始化时，RequestMappingHandlerMapping 会扫描所有的 beans，查找带有 @RequestMapping 注解的方法，并注册这些方法作为哀求的处理器。
[*]映射处理：RequestMappingHandlerMapping 使用 Pattern 对象来存储和匹配 URL 模式。
[*]getHandler 方法实现：
@Override
public Mono<Object> getHandler(ServerWebExchange exchange) {
String lookupPath = getPath(exchange);
return getHandlerInternal(exchange)
.filter(h -> matchesRoute(lookupPath, h))
.switchIfEmpty(Mono.defer(() -> getBestMatchingHandler(lookupPath, exchange)));
}
[*]getPath：从 ServerWebExchange 中提取哀求路径。
[*]getHandlerInternal：返回一个包罗所有注册处理器的 Mono。
[*]filter 和 matchesRoute：检查处理器是否与哀求路径匹配。
[*]getBestMatchingHandler：假如没有找到精确匹配的处理器，实验找到最佳匹配的处理器。
映射匹配逻辑
映射匹配逻辑通常涉及以下步骤：
[*]路径匹配：检查哀求的路径是否与注册的 URL 模式匹配。
[*]哀求方法匹配：假如 URL 模式匹配，进一步检查哀求的方法（GET、POST 等）是否与处理器支持的方法匹配。
[*]参数条件匹配：检查哀求是否包罗处理器所需的参数。
[*]头信息匹配：检查哀求头是否满足特定的条件。
[*]消费和产生媒体类型匹配：检查哀求的 Accept 头和 Content-Type 是否与处理器支持的媒体类型匹配。
性能优化
RequestMappingHandlerMapping 还实现了一些性能优化步伐，比方缓存匹配的 URL 模式，以镌汰重复的模式匹配操作。
小结一下
HandlerMapping 组件是 Spring WebFlux 哀求处理流程中的关键部分，它负责将进入的哀求映射到精确的处理器。通过使用不同的 HandlerMapping 实现，Spring WebFlux 支持灵活的哀求映射策略，以适应不同的应用场景。
3. HandlerAdapter
HandlerAdapter 接口在 Spring WebFlux 中扮演着至关紧张的脚色，它的作用是将 DispatcherHandler 找到的处理器（handler）适配到详细的执行逻辑上。HandlerAdapter 使得 DispatcherHandler 无需关心详细的处理器类型，只需要通过 HandlerAdapter 来调用处理器即可。以下是对 HandlerAdapter 组件的源码实现逻辑和步骤的详细分析：
HandlerAdapter 接口界说
HandlerAdapter 接口界说了以下关键方法：
public interface HandlerAdapter {
boolean supports(Object handler);
Mono<Void> handle(ServerWebExchange exchange, Object handler, Object... args);
}
[*]supports：检查给定的处理器是否被当前 HandlerAdapter 支持。
[*]handle：调用处理器，并返回一个 Mono 对象，表现异步的调用过程。
重要实现类
Spring WebFlux 提供了几个 HandlerAdapter 的实现类，重要包罗：
[*]RequestMappingHandlerAdapter：支持基于注解的控制器方法，如带有 @RequestMapping 注解的方法。
[*]HttpHandlerAdapter：支持 HttpHandler 接口的处理器。
[*]ControllerEndpointHandlerAdapter：支持 ControllerEndpoint 接口的处理器，通常用于 WebFlux 函数式编程。
[*]RouterFunctionHandlerAdapter：支持 RouterFunction 接口，用于函数式路由。
RequestMappingHandlerAdapter 源码分析
RequestMappingHandlerAdapter 是最常用的 HandlerAdapter 实现之一，下面是它的一些关键实现逻辑：
[*]支持性检查：supports 方法检查给定的处理器是否是 Controller 大概 RequestMapping 注解的方法。
@Override
public boolean supports(Object handler) {
return (handler instanceof HandlerFunction) ||
(handler instanceof Controller) ||
AnnotationUtils.findAnnotation(handler.getClass(), RequestMapping.class) != null;
}调用处理器：handle 方法调用处理器，并处理返回值。
@Override
public Mono<Void> handle(ServerWebExchange exchange, Object handler) {
// 调用具体的处理器
return ((HandlerFunction<ServerResponse>) handler).handle(exchange);
}调用处理器的逻辑
调用处理器的逻辑通常涉及以下步骤：
[*]参数剖析：剖析哀求中的参数，并将其转换为方法参数。
[*]调用方法：调用处理器的方法，并将剖析后的参数传递给方法。
[*]处理返回值：处理方法的返回值，将其转换为相应。
[*]异步处理：假如处理器返回的是 Mono 或 Flux，HandlerAdapter 需要处理这些异步效果。
错误处理
HandlerAdapter 还负责处理调用过程中的非常，将非常转换为合适的相应。
小结一下
HandlerAdapter 组件是 Spring WebFlux 哀求处理流程中的关键部分，它解耦了 DispatcherHandler 和详细的处理器实现。通过使用不同的 HandlerAdapter 实现，Spring WebFlux 支持了多种类型的处理器，包罗基于注解的控制器、函数式路由以及 HttpHandler 接口的实现。这种计划提高了框架的灵活性和可扩展性。
4. HandlerResultHandler
HandlerResultHandler 组件在 Spring WebFlux 中负责处理由 HandlerAdapter 调用处理器后返回的效果。它将这些效果转换为客户端可以接收的 HTTP 相应。以下是对 HandlerResultHandler 组件的源码实现逻辑和步骤的详细分析：
HandlerResultHandler 接口界说
HandlerResultHandler 接口界说了以下关键方法：
public interface HandlerResultHandler {
boolean supports(HandlerResult result);
Mono<Void> handleResult(ServerWebExchange exchange, HandlerResult result);
}
[*]supports：检查给定的 HandlerResult 是否被当前 HandlerResultHandler 支持。
[*]handleResult：处理 HandlerResult，生成相应并返回一个 Mono 对象，表现异步的处理过程。
重要实现类
Spring WebFlux 提供了几个 HandlerResultHandler 的实现类，重要包罗：
[*]ServerResponseResultHandler：处理 ServerResponse 类型的返回值。
[*]ResponseEntityResultHandler：处理 ResponseEntity 类型的返回值。
[*]ModelAndViewResultHandler：处理 ModelAndView 类型的返回值，通常用于视图渲染。
ServerResponseResultHandler 源码分析
ServerResponseResultHandler 是处理 ServerResponse 类型效果的 HandlerResultHandler 实现：
[*]支持性检查：supports 方法检查 HandlerResult 是否包罗 ServerResponse 对象。
@Override
public boolean supports(HandlerResult result) {
return result.getReturnValue() instanceof ServerResponse;
}
[*]处理效果：handleResult 方法处理 ServerResponse 对象，并生成相应。
@Override
public Mono<Void> handleResult(ServerWebExchange exchange, HandlerResult result) {
ServerResponse response = (ServerResponse) result.getReturnValue();
return response.writeTo(exchange, result.isCommitted());
}处理效果的逻辑
处理效果的逻辑通常涉及以下步骤：
[*]获取返回值：从 HandlerResult 中获取处理器的返回值。
[*]检查类型：根据返回值的类型，选择合适的处理逻辑。
[*]生成相应：将返回值转换为 HTTP 相应。比方，ServerResponse 已经包罗了相应的状态码、头信息和体。
[*]异步处理：假如返回值是异步的（如 Mono 或 Flux），则需要处理这些异步效果。
[*]写入相应：将生成的相应写入到 ServerWebExchange 中。
错误处理
HandlerResultHandler 还负责处理效果处理过程中的非常，将非常转换为合适的相应。
小结一下
HandlerResultHandler 组件是 Spring WebFlux 哀求处理流程中的关键部分，它负责将处理器的返回值转换为 HTTP 相应。通过使用不同的 HandlerResultHandler 实现，Spring WebFlux 支持了多种返回值类型，包罗 ServerResponse、ResponseEntity 和 ModelAndView。这种计划提高了框架的灵活性和可扩展性，答应开发者以不同的方式处理相应效果。
HandlerResultHandler 的实现通常需要考虑相应的异步特性，确保纵然在异步流的情况下也能精确地生成和发送相应。此外，它还需要与 ServerWebExchange 精密协作，以便访问和操作哀求和相应的上下文信息。
5. WebFilter
WebFilter 接口是 Spring WebFlux 中用于拦截和处理 Web 哀求和相应的组件。它答应开发者在哀求到达详细的处理器之前或之后，对哀求或相应进行额外的处理，比方日志记录、安全性检查、跨域处理等。以下是对 WebFilter 组件的源码实现逻辑和步骤的详细分析：
WebFilter 接口界说
WebFilter 接口界说了以下关键方法：
public interface WebFilter {
Mono<Void> filter(ServerWebExchange exchange, WebFilterChain chain);
}
[*]filter：对给定的 ServerWebExchange 对象进行处理，并通过 WebFilterChain 调用链中的下一个 WebFilter 或最终的处理器。
过滤器链
在 Spring WebFlux 中，WebFilter 通常会被组织成一个过滤器链，每个 WebFilter 都可以决定是继续过滤哀求还是将哀求传递给链中的下一个 WebFilter。这种链式调用模式使得过滤器的执行顺序非常紧张。
重要实现类
Spring WebFlux 提供了一些内置的 WebFilter 实现类，比方：
[*]ServerHttpSecurity：用于安全性检查。
[*]CorsFilter：用于处理跨源资源共享（CORS）。
[*]WebFilterChain：代表过滤器链的上下文，答应调用链中的下一个 WebFilter。
过滤器链的构建
过滤器链通常在应用程序的配置中构建，比方使用 WebFilter 接口的实现类：
@Configuration
public class WebFluxConfig {
@Bean
public WebFilter myCustomFilter() {
return (exchange, chain) -> {
// 在这里可以对请求进行预处理
return chain.filter(exchange).subscriberContext(ctx -> ctx.put("customKey", "customValue"));
};
}
}WebFilter 的实现逻辑
实现 WebFilter 接口的 filter 方法通常涉及以下步骤：
[*]预处理：在调用 chain.filter(exchange) 之前，对 ServerWebExchange 进行任何必要的预处理，比方修改哀求头、查询参数等。
[*]调用链：使用 WebFilterChain 的 filter 方法将哀求传递给链中的下一个 WebFilter。这通常会返回一个 Mono，表现异步的过滤过程。
[*]后处理：在 chain.filter(exchange) 完成后，对 ServerWebExchange 进行任何必要的后处理，比方修改相应头、相应体等。
[*]错误处理：处理在过滤过程中可能发生的非常，并决定是抛出新的错误、返回特定的相应或继续过滤链。
异步处理
由于 filter 方法返回的是 Mono，WebFilter 的实现需要考虑异步处理。这意味着在过滤过程中，可以返回异步的相应，而不会阻塞整个哀求的处理。
小结一下
WebFilter 组件是 Spring WebFlux 中用于拦截和处理 Web 哀求和相应的强大工具。通过实现 WebFilter 接口并构建过滤器链，开发者可以灵活地对哀求和相应进行预处理和后处理，以及实现各种横切关注点，如安全性、日志记录、CORS 处理等。这种计划提高了应用程序的模块性和可维护性，同时保持了非阻塞和异步的特性。
6. ServerWebExchange
ServerWebExchange 是 Spring WebFlux 中的一个核心组件，它封装了 HTTP 哀求和相应的上下文信息，为 Web 服务器和应用程序之间提供了一个交互的接口。以下是对 ServerWebExchange 组件的源码实现逻辑和步骤的详细分析：
ServerWebExchange 接口界说
ServerWebExchange 接口界说了对 HTTP 哀求和相应的访问和操作：
public interface ServerWebExchange {
ServerHttpRequest getRequest();
ServerHttpResponse getResponse();
void beforeCommit();
boolean isCommitted();
void setCommitted(boolean committed);
Context getContext();
}
[*]getRequest()：返回当前的 ServerHttpRequest 对象，包罗哀求的详细信息。
[*]getResponse()：返回当前的 ServerHttpResponse 对象，用于构造相应。
[*]beforeCommit()：在相应提交之前调用，答应进行一些清理或准备操作。
[*]isCommitted()：检查相应是否已经提交。
[*]setCommitted(boolean committed)：设置相应是否提交的状态。
[*]getContext()：返回与当前互换关联的 Context，用于存储和传递附加信息。
核心属性
ServerWebExchange 通常包罗以下核心属性：
[*]request：ServerHttpRequest 对象，封装了 HTTP 哀求的详细信息，如头信息、URI、方法等。
[*]response：ServerHttpResponse 对象，用于构造和发送 HTTP 相应。
[*]principal：可能包罗当前哀求的认证主体（Principal）。
[*]session：可能包罗当前哀求的会话信息。
[*]attributes：一个 Map，用于存储与哀求相干的属性。
哀求和相应的处理
ServerWebExchange 在哀求和相应的处理中扮演着核心脚色：
[*]哀求获取：通过 getRequest() 方法获取哀求对象，访问哀求的各种信息。
[*]相应构造：通过 getResponse() 方法获取相应对象，构造相应的状态码、头信息和相应体。
[*]上下文管理：使用 Context 对象存储和传递哀求和相应过程中的附加信息。
[*]提交管理：通过 beforeCommit()、isCommitted() 和 setCommitted() 方法管理相应的提交状态。
[*]过滤器链：在 WebFilter 的实现中，ServerWebExchange 对象在过滤器链中传递，每个过滤器都可以访问和修改哀求和相应。
异步处理
由于 WebFlux 是相应式的，ServerWebExchange 支持异步处理：
[*]相应可以通过非阻塞的方式写入，比方使用 ServerHttpResponse 的异步方法。
[*]哀求和相应的处理可以在不同的线程或事件循环中进行。
小结一下
ServerWebExchange 是 Spring WebFlux 中处理 HTTP 哀求和相应的核心组件。它提供了一个同一的接口来访问和操作哀求和相应数据，同时支持异步非阻塞的处理方式。通过 ServerWebExchange，开发者可以在 Web 服务器和应用程序之间进行高效的数据互换和状态管理，实现高性能的相应式 Web 应用。
ServerWebExchange 的实现通常需要考虑相应式的编程模型，确保在处理哀求和构造相应时不会阻塞事件循环，从而充分利用 WebFlux 的性能优势。此外，它还提供了丰富的上下文管理功能，使得在复杂的哀求处理流程中，可以方便地存储和传递附加信息。
7. ServerHttpRequest和ServerHttpResponse
ServerHttpRequest 和 ServerHttpResponse 是 Spring WebFlux 中的两个核心接口，它们分别表现服务器接收的 HTTP 哀求和发送的 HTTP 相应。以下是对这两个组件的源码实现逻辑和步骤的详细分析：
ServerHttpRequest 接口界说
ServerHttpRequest 接口界说了对 HTTP 哀求的访问：
public interface ServerHttpRequest {
URI getURI();
HttpMethod getMethod();
String getHeader(String headerName);
MultiValueMap<String, String> getHeaders();
DataBufferFactory bufferFactory();
// 省略其他方法...
}
[*]getURI()：返回哀求的 URI。
[*]getMethod()：返回 HTTP 方法（如 GET、POST 等）。
[*]getHeader(String headerName)：根据名称获取哀求头的值。
[*]getHeaders()：返回包罗所有哀求头的 MultiValueMap。
[*]bufferFactory()：返回用于创建数据缓冲区（DataBuffer）的工厂。
ServerHttpResponse 接口界说
ServerHttpResponse 接口界说了对 HTTP 相应的构造和发送：
public interface ServerHttpResponse { HttpStatusSeriesStatus.Series getStatusSeries(); void setStatusCode(HttpStatus statusCode); String getHeader(String headerName); MultiValueMap getHeaders(); void setComplete(); DataBufferFactory bufferFactory(); Mono writeWith(Publisher
页:
[1]